Re: [TLS] TLS1.3 clarification request
On Tue, 16 Mar 2021, 20:03 Jeremy Harris, wrote: > On 16/03/2021 07:53, Ben Smyth wrote: > > Further, is it reasonable for the above first end to > >> expect the above second end to continue processing and > >> sending data that would have been sent in the absence of > >> such a first Close Alert? > >> > > > > The endpoint should expect their interlocutor to ignore any data received > > after the alert: Any data received after a closure alert has been > received > > MUST be ignored. > > > > The endpoint should expect any data sent before raising alert > close_notify > > to be delivered: It is assumed that closing the write side of a > connection > > reliably delivers pending data before destroying the transport. > > > > Whether an interlocutor processes data sent before alert close_notify is > > seemingly not governed by the specification, which seems reasonable. > > So, that doesn't directly answer that portion of my question - but > does appear to make a half-close useless, by requiring an end > to hold off sending a Close alert until after if has received all > data that the far end is expected to send. > > Do I understand that right? And if so, what is the point of the > language in the RFC that appears to permit a half-close? Specifications don't define systems, they guide design. The specification does not "requir[e] an end to hold off sending a Close alert until after if has received all data that the far end is expected to send," the specification merely allows such behaviour. Perhaps one scenario where that behaviour is useful: An endpoint is about to be comprimised and raises an alert to avoid secrets being leaked. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ECH/ESNI - is accept confirmation calculation brittle in the face of errors?
Oh, that is a good observation. If the client has the same ServerHello-sensitive preferences (version, key share, supported groups, cipher suites, PSKs) between inner and outer ClientHello, it doesn't need to reprocess. But if it has different preferences, it needs to resolve this circular dependency. Most of the ServerHello-sensitive preferences are actually currently required to match, otherwise HRR doesn't work, but hopefully we'll fix HRR and remove this awkward restriction. But the key word is *most* because PSKs do differ between the two. It would be weird if the client could be tricked into completing an outer ClientHello handshake with an inner ClientHello PSK. I suspect it's "merely" weird, but we should not so easily get implementations into self-inconsistent states. The stuff in ServerHello is sufficiently constrained that this is probably not fatal. Realistically, the two handshakes are sufficiently intertwined on the client at this point that it'll probably need to be careful about the inner/outer point regardless. But I agree it's not great and worth looking at again. I think the mechanism in https://github.com/tlswg/draft-ietf-tls-esni/pull/287 did not have this circular dependency, but it was introduced in https://github.com/tlswg/draft-ietf-tls-esni/pull/353. I forget, did we need to bind it to the actual handshake secret, or was the transcript and ClientHelloInner.random sufficient? That would avoid the circular processing dependency. David On Tue, Mar 16, 2021 at 10:06 PM Stephen Farrell wrote: > > Hi all, > > I raised a github issue [1] related to (but different from) > this but would prefer a discussion via email if that's ok. > Depending how this goes, I can create a new GH issue I guess. > > ECH draft-09 (and -10) requires the client to verify that the > server has processed ECH by comparing 8 octets in the > ServerHello.random with a value one can only know if you know > the inner CH octets and (pretty much all) the rest of the > h/s so far. That seemingly removes the need for the client to > maybe decrypt twice (once based on inner CH, once based on > outer) to see what works. That can be implemented ok for > the nominal case. As far as I can see that was the result of > github issue #274 [2] back in Aug/Sep 2020. > > But in error cases that seems to require the client to > possibly process the same ServerHello extensions twice, > which could have side effects, is generally ickky and > I think shows that this aspect of the design maybe needs a > change. That's not much different from trial decryption > really. In my current, (and still horrible;-), OpenSSL code > the minimal effect is memory leaks for error cases that are > tricky to handle, but can be handled, although at the expense > of probably making the code even more brittle. (Note: I'm > neither defending nor attacking the way OpenSSL handles > extensions here:-) > > The specific problem is one needs the handshake secret to > calculate the 8 octets one expects in the ServerHello.random, > but generating the handshake secret typically involves a key > share ServerHello extension and might in future involve some > PQC stuff, so I think we can't say for sure which subset of > extensions are needed for the calculation. And if the first > time doesn't give the right answer (e.g. if the client used > the wrong ECHConfig) then you gotta process the ServerHello > incl. its extensions a 2nd time. > > I think the requirement we ought try meet here is that any > confirmation value needs to be something the client can > calculate using values known before the SH is rx'd plus the > ServerHello as a (mostly) unprocessed buffer. That could be > e.g. some hash of the encoded inner CH, ECHConfig and the > ServerHello maybe. Some of those issues were discussed in [2] > already and in an interim meeting I missed but I reckon it > might be worthwhile thinking again. > > Thanks, > S. > > [1] https://github.com/tlswg/draft-ietf-tls-esni/issues/399 > [2] https://github.com/tlswg/draft-ietf-tls-esni/issues/274 > > > > ___ > 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] TLS1.3 clarification request
On Wed, Mar 17, 2021 at 08:15:53AM +0100, Ben Smyth wrote: > > Do I understand that right? And if so, what is the point of the > > language in the RFC that appears to permit a half-close? > > Specifications don't define systems, they guide design. The specification > does not "requir[e] an end to hold off sending a Close alert until after if > has received all data that the far end is expected to send," the > specification merely allows such behaviour. Perhaps one scenario where that > behaviour is useful: An endpoint is about to be comprimised and raises an > alert to avoid secrets being leaked. FWIW, I largely part ways with Ben's assessment, and particularly the strawman scenario above. TLS 1.3 does in fact make it possible to support half-close in mutually cooperative applications, and there is no expectation that a close-notify on one side must immediately be accompanied by a similar action on the other, the other side can continue to send applicatoin data traffic. However, what I don't read into 8446 is an obligation or expectation that applications will routinely support half close. Some probably should (e.g. an HTTPS server should probably continue with its response even after a half-close on the client-side following the request). However, if applications don't support half-close, and fail to respond to prior requests upon receipt of close-notify, I don't think they're violating the specification, they're merely not half-close compatible. If some application protocol is expected to support half-close, that should be specified in some relevant application-specific standard. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 clarification request
On 17/03/2021 07:15, Ben Smyth wrote: Perhaps one scenario where that behaviour is useful: An endpoint is about to be comprimised and raises an alert to avoid secrets being leaked. I'd have tout that a section 6.2 Error Alert would be more appropriate in such a situation, than the (implicitly non-error) section 6.1 Closure Alert I'm discussing. Do you at least agree that Google is in violation of the 6.1 wording requiring that it sends a Close Alert before sending a TCP FIN? -- Cheers, Jeremy ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 clarification request
On Wed, 17 Mar 2021, 15:31 Jeremy Harris, wrote: > On 17/03/2021 07:15, Ben Smyth wrote: > > Perhaps one scenario where that > > behaviour is useful: An endpoint is about to be comprimised and raises an > > alert to avoid secrets being leaked. > > I'd have tout that a section 6.2 Error Alert would be more > appropriate in such a situation, than the (implicitly > non-error) section 6.1 Closure Alert I'm discussing. > > Do you at least agree that Google is in violation of the 6.1 > wording requiring that it sends a Close Alert before sending > a TCP FIN? > Which aspect of Section 6.1 do you think Google doesn't comply with? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 clarification request
On 17/03/2021 14:45, Ben Smyth wrote: Do you at least agree that Google is in violation of the 6.1 wording requiring that it sends a Close Alert before sending a TCP FIN? Which aspect of Section 6.1 do you think Google doesn't comply with? "Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert." -- Cheers, Jeremy ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Hopefully-final draft-ietf-dnsop-svcb-https-04 and nearing WGLC
We've closed out most of the open issues on draft-ietf-dnsop-svcb-https and it will be going to WGLC shortly. Current version at: https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-04.txt Hopefully we're done, but you can open issues against: https://github.com/MikeBishop/dns-alt-svc This will likely get batched up while waiting for TLS ECH to publish due to some cross-dependencies. Change history for the last few versions: o draft-ietf-dnsop-svcb-https-04 * Simplify the IANA instructions (pure First Come First Served) * Recommend against publishing chains of >8 aliases * Clarify requirements for using SVCB with a transport proxy * Adjust guidance for Port Prefix Naming * Minor editorial updates o draft-ietf-dnsop-svcb-https-03 * Simplified escaping of comma-separated values * Reorganized client requirements * Added a warning about port filtering for cross-protocol attacks * Clarified self-consistency rules for SvcParams * Added a non-normative mapping summary table for HTTPS o draft-ietf-dnsop-svcb-https-02 * Added a Privacy Considerations section * Adjusted resolution fallback description * Clarified status of SvcParams in AliasMode * Improved advice on zone structuring and use with Alt-Svc * Improved examples, including a new Multi-CDN example * Reorganized text on value-list parsing and SvcPriority * Improved phrasing and other editorial improvements throughout o draft-ietf-dnsop-svcb-https-01 * Added a "mandatory" SvcParamKey * Added the ability to indicate that a service does not exist * Adjusted resolution and ALPN algorithms * Major terminology revisions for "origin" and CamelCase names * Revised ABNF * Include allocated RR type numbers * Various corrections, explanations, and recommendations o draft-ietf-dnsop-svcb-https-00 * Rename HTTPSSVC RR to HTTPS RR * Rename "an SVCB" to "a SVCB" * Removed "design considerations and open issues" section and some other "to be removed" text -- Forwarded message - A new version of I-D, draft-ietf-dnsop-svcb-https-04.txt has been successfully submitted by Ben Schwartz and posted to the IETF repository. Name: draft-ietf-dnsop-svcb-https Revision: 04 Title: Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) Document date: 2021-03-17 Group: dnsop Pages: 48 URL: https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-04.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https Htmlized: https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-04 Abstract: This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTPS origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP origins. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc [1]. The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
