Re: [TLS] Integrity bounds in DTLS
On 18/05/2020, 01:47, "Martin Thomson" wrote: > The question is whether it is clear that these limits apply to the use > of AEADs in TLS more generally. I think that is clear enough, but I > doubt that people will pay any mind unless they are implementing TLS > 1.3. Yes, that's exactly my original point. I'd like to maximise the chance that the message doesn't get ignored: we have 1.2 deployments around that are not likely to be forklifted to 1.3 soon and will have to make them aware of the risk nonetheless. > The problem with TLS 1.2 is that there is no option for key updates, > unless you count renegotiation, which is often disabled. When I added > limits to NSS, all I could reliably do was make the connection > terminate if the limit was hit (which is why the limits used are > larger than advised in the spec). Sure, protocol version as well as stack specific reactions will differ. I guess my question is whether, to maximise coverage/visibility, it makes sense to state the general problem together with version specific behaviours in a separate doc? IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Bikeshedding ECHO
I am glad this bikeshed was shorter than I expected. Because most people didn’t have a strong preference and there might be some (possibly small) chance of confusion, it seems like we should change the name to ETCH (Encrypted TLS Client Hello). spt > On May 7, 2020, at 18:52, Christopher Wood wrote: > > Erik raises some compelling reasons to change the name from ECHO to... > something else less confusing or misleading [1]. Candidates from the PR > include ETCH (Encrypted TLS Client Hello), ECH, and EHELLO. Since the > HTTPSSVC draft aims for WGLC before IETF 108, it would be good if we got this > bikeshedding out of the way now. To that end, if you have an opinion on the > name and whether or not we should change it, please share it! > > Thanks, > Chris (no hat) > > [1] https://github.com/tlswg/draft-ietf-tls-esni/issues/232 > > ___ > 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] Bikeshedding ECHO
If we must change it, let's do ECH, as the T seems entirely superfluous. After all, it's not TSNI. -Ekr On Tue, May 19, 2020 at 5:32 AM Sean Turner wrote: > I am glad this bikeshed was shorter than I expected. Because most people > didn’t have a strong preference and there might be some (possibly small) > chance of confusion, it seems like we should change the name to ETCH > (Encrypted TLS Client Hello). > > spt > > > On May 7, 2020, at 18:52, Christopher Wood wrote: > > > > Erik raises some compelling reasons to change the name from ECHO to... > something else less confusing or misleading [1]. Candidates from the PR > include ETCH (Encrypted TLS Client Hello), ECH, and EHELLO. Since the > HTTPSSVC draft aims for WGLC before IETF 108, it would be good if we got > this bikeshedding out of the way now. To that end, if you have an opinion > on the name and whether or not we should change it, please share it! > > > > Thanks, > > Chris (no hat) > > > > [1] https://github.com/tlswg/draft-ietf-tls-esni/issues/232 > > > > ___ > > 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] Comments on draft-ietf-tls-external-psk-importer-04
We chatted offline and updated the draft to refine some points: https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/36 Thanks for helping improving the document! Best, Chris On Mon, Apr 27, 2020, at 7:08 AM, Hollenbeck, Scott wrote: > > -Original Message- > > From: Christopher Wood > > Sent: Friday, April 24, 2020 7:09 PM > > To: Hollenbeck, Scott ; TLS@ietf.org > > Subject: [EXTERNAL] Re: [TLS] Comments on draft-ietf-tls-external-psk- > > importer-04 > > [snip] > > > > > Hmm, not quite. The statement intends to say that if you need EPSK k > > > > into an importer and into TLS 1.2 then the resulting keys used in > > > > TLS 1.3 and 1.2 are different. I'm not sure further clarification is > > > > needed, though I'm happy to review suggestions if you have them! > > > > > > Agree with that as the goal. Here's our concern in brief. If our > > > understanding is correct, prior to this draft, the client could use an > > > EPSK k in two ways: > > > > > > * as input to the TLS 1.2 PRF (based on any hash function) > > > * as input to the TLS 1.3 key schedule via HKDF-extract (based on a > > > single hash function) > > > > > > Following this draft, the client could use k in two ways: > > > > > > * as input to the TLS 1.2 PRF (based on any hash function) [same as > > > before] > > > * as input to the importer function via HKDF-extract (based on a > > > single hash function) > > > > > > So there is still a potential cryptographic overlap in the use of k > > > between TLS 1.2 and TLS 1.3. The imported keys don't have this > > > overlap, because they're separated from one another and from the > > > underlying EPSK through the use of the importer function. But doesn't > > > the security proof for k still need to take into account that the > > > input to HKDF-extract might also be input to the TLS 1.2 PRF (with the > > > same or a different hash function)? > > > > > > In other words, if it was a problem for the security proof that k > > > could be input to the PRF and to HKDF-extract before the draft, isn't > > > it still a problem afterwards? The conclusion that there are no > > > cross-protocol collisions depends on the specifics of the TLS 1.2 PRF > > > and how it's used, compared to HKDF-extract. > > > > > > We're not suggesting there is any attack here, just trying to > > > understand the design actually addresses the statement in the > > > introduction that k "could possibly be re-used in two different > > > contexts with the same hash functions during key derivation". > > > > For lack of a better way to describe this (sorry!), we're trying to avoid > > this > > input collision during the key derivation process of a TLS connection. As > > the > > importer happens before a connection, and can be viewed as part of the > > provisioning process that produces unique PSKs for each target hash > > function, we achieve the goal for TLS 1.3 of not re-using a PSK with > > different > > hash functions. > > > > I'm not sure how to better clarify that right now, so suggestions are very > > much welcome. > > We're okay with the arguments in the draft that the design preserves > security proofs when the same EPSK is used to produce internal PSKs > associated with different hash functions within TLS 1.3 only. However, > it isn't clear enough to us how the design preserves security proofs > when the same EPSK is used with both TLS 1.2 and TLS 1.3. I don't yet > have any text to suggest, because we're not sure we understand the > rationale. What is the rationale for the design in that situation? > > Scott > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] I-D Action: draft-ietf-tls-external-psk-importer-05.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Importing External PSKs for TLS Authors : David Benjamin Christopher A. Wood Filename: draft-ietf-tls-external-psk-importer-05.txt Pages : 11 Date: 2020-05-19 Abstract: This document describes an interface for importing external Pre- Shared Keys (PSKs) into TLS 1.3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-05 https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-importer-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-external-psk-importer-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Bikeshedding ECHO
As a data point, I was fairly confused when ECHO came up in conversation, and had to stop to ask what it was. I think I would have had a better chance of figuring it out from context or search if it were called ECH, but don't have a strong preference for any specific name. ECH does have a remarkable short Wikipedia disambiguation list, FWIW. https://en.wikipedia.org/wiki/ECH Filippo___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
