Re: [TLS] [kitten] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard
gt; messages, and vice versa. >> > >> > There isn't even a one-to-one relationship between GSS-API / SCRAM >> > runs. This channel binding design doesn't protect against messages >> > being swapped between two GSS-API runs on a single TLS connection. >> > Again, whether that is a specific problem for GSS-API is totally >> > irrelevant. Another protocol that uses this draft may well be >> > vulnerable, and thus this is just leaving a huge security landmine >> > in TLS channel bindings. >> > >> > At an absolute minimum this draft should include "A TLS session >> > using this RFC to produce a binding for any purpose MUST NOT >> > generate more than one per session. If a second exporter using this >> > protocol is required the TLS session MUST be rekeyed." >> > >> Can you please elaborate a bit more on this particular attack vector? >> What exactly information it may leak/compromise and how? >> >> The reason I'm asking is that application is the one glueing together >> TLS and authentication sessions, however application does not always >> have access to internals of either one(tls), or another(auth) or even >> both. Therefore asking application to transfer context between >> authentication and transport APIs may not always be feasible or even >> possible. >> >> Regards, Ruslan >> >> -- Sam Whited ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard
8446 currently contains: > However, it is also possible to bind such connections to an external > authentication mechanism via out-of-band validation of the server's > public key, trust on first use, or a mechanism such as channel > bindings (though the channel bindings described in [RFC5929] are not > defined for TLS 1.3). If I were part of the TLS group I'd want to see discussion of the the parenthetical at the end being replaced with something like: "such as the bindings defined in ". Then the parenthetical could be moved to the security considerations section or similar (right now it's quite hard to find). At the risk of veering into 8446 feedback, I have gotten a lot of push back when I mentioned that the RFC5929 channel bindings weren't defined for TLS 1.3 in the past, normally something along the lines of "that's just one random throw-away sentence in the middle of the document, why should I not implement this?" That being said, I haven't really thought about this and don't know whether this would be appropriate or not, I'm just trying to respond to your query with some initial thoughts. None of this should be taken as what I've been pushing for in the rest of this thread. —Sam On Sun, Oct 3, 2021, at 15:02, Eric Rescorla wrote: > Sorry to be difficult, but as I said, I'd prefer to focus not on the > question of the header of this document but rather on what we wish > 8446 said. To that end, what text do you think should go in 8446-bis? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard
I'd be okay with that provided we can release an update if such an analysis is ever done? Although this is such a low-stakes issue that I worry that the prejudicial value of such a statement far outweighs the security value. I don't feel strongly about it though. —Sam On October 3, 2021 1:06:40 PM UTC, "Salz, Rich" wrote: >Perhaps adding text that says no security analysis has been done. > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard
Even if linking this in updates implied confidence (though I don't think it does), TLS alread implies confidence in its own EKM mechanism. I don't believe this document expands on that. For example, it does not detail any particular use of channel binding. —Sam On Sat, Oct 2, 2021, at 13:12, Eric Rescorla wrote: > I want to be clear that I don't think this is about credit. My concern > is purely about accurately reflecting the level of confidence one > should have in this mechanism. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard
This is just a registration with IANA more than anything else; this required almost no work compared to the many people and many years spent on TLS. I don't believe marking this as an update implies any flaw in TLS, or any presumption that this is somehow its equal in terms of effort. This isn't a competition, it's just logically part of the same ecosystem. If we start thinking about one document referencing or updating another as somehow being presumptuous or implying that we're trying to retcon the other authors work I don't see the culture of the IETF ever becoming a very inviting one. Similarly, if we decide that every document that updates another document has to be its equal in terms of effort, no documents will ever get updates until they are ready to be entirely replaced. Lots of documents receive small updates, this is no different. Would it make a difference if I added a section thanking the TLS authors for their work and for including bits like EKM that make keying material possible? I'd be happy to include such a section if it would make people feel better about it. —Sam On Fri, Oct 1, 2021, at 23:32, Rob Sayre wrote: > Makes sense a goal—I think the objection is more that updating 8446 on > paper here is presumptuous, since that document took orders of > magnitude more work. > > That should not detract from the work in this new draft, but hopefully > my message at least makes the disagreement more clear. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard
No, I am saying that I have seen people implement custom solutions to problems in an RFC because they don't realize that there is a related RFC that fixes those problems (or suggests how to do whatever tangential thing they needed to implement). Having a link in the related RFCs make things easier to discover. In this case, if I was someone wanting to, for example, implement channel binding between TLS and some sort of authentication token so that the token would not remain valid if the TLS session changed, I would probably go to the TLS spec to see if such a thing exists. If that spec doesn't contain the "Updated by" link, I don't think it's as likely that I'd find that there was a standard way to do this. —Sam On Fri, Oct 1, 2021, at 23:11, Rob Sayre wrote: > On Fri, Oct 1, 2021 at 8:04 PM Sam Whited wrote: > >> I have to respectfully disagree with this. >> >> Anecdotally, RFCs are hard to discover. > > > > What do you mean, exactly, here? > > Are you saying that this draft “update” 8446 in order for readers to > understand it and 8446 itself? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] last call: draft-ietf-kitten-tls-channel-bindings-for-tls13-02
Re-iterating that CBs may be public seems sane. I'll add some text. along the lines of: > Channel bindings do not leak secret information about the channel and > are considered public. Implementations MUST NOT use the channel > binding to protect secret information. With regard to context strings, I don't think it gets us any benefit. If two protocols get the same channel binding and something changes (eg. the protocol is resumed over a new TLS session), both channel bindings break either way. We'd also want to create some sort of registry for these strings, most likely which adds a lot of overhead for no benefit that I can see. Maybe there's some benefit to having separate channel bindings per protocol and per channel and not just per channel that I can't see though. —Sam On Wed, Mar 10, 2021, at 18:57, Jonathan Hoyland wrote: > IIUC a channel binding (in this context) provides a unique "name" for > a channel. In the case where two distinct protocols running over the > top of TLS use this definition, they will both get the same channel > binding. It might be useful to pull out in the security considerations > one consideration from RFC 5056 that might be forgotten. > > ``` o The integrity of a secure channel MUST NOT be weakened should > their channel bindings be revealed to an attacker. That is, the > construction of the channel bindings for any type of secure channel > MUST NOT leak secret information about the channel. [...] ``` > > This means that a perfectly valid (even if currently undefined) use of > a channel binding might involve posting it to Twitter. I don't follow > kitten, but if there are multiple places that use this binding then > this might be a useful warning. You cannot assume the channel binding > of a channel is secret. > > Alternatively using context strings allows for independent channel > bindings to be used by each over-the-top protocol, so perhaps > requiring some unique context string per usage type might be > appropriate. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Export Channel Binding
about whether that was > > > actually secure, but at first glance it seems like a reasonable > > > approach. > > > > > > Channel bindings that bind both the underlying channel and the > > > higher-level protocol make more sense to me that channel bindings > > > that only identify the underlying channel, because you don't have > > > to worry about the (potentially pathological) behaviours of other > > > users of the binding. > > > > > Best Regards, > > > > Alexey > > > Regards, > > Jonathan > > [1] Bhargavan, Karthikeyan, Antoine Delignat-Lavaud, and Alfredo > Pironti. "Verified Contributive Channel Bindings for Compound > Authentication." *NDSS*. 2015. > > https://prosecco.gforge.inria.fr/personal/karthik/pubs/verified-channel-bindings-ndss15.pdf -- Sam Whited ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] NIST crypto group and HKDF (and therefore TLS 1.3)
On Fri, May 8, 2020, at 17:08, Salz, Rich wrote: > It cites it, but doesn't include it in the 800-56 doc. Maybe I'm confused too, but it sounds like it's included to me. The definition of the KDF includes: > The first (randomness-extraction) step uses either HMAC … If > HMAC-hash is used in the randomness- extraction step, then the same > HMAC-hash (i.e., using the same hash function, hash) shall be used as > the PRF in the key-expansion step This sounds like this would allow for HKDF as defined in RFC 5869 (which as far as I can tell is the same thing except with HMAC required in both steps instead of giving you the option of using AES-CMAC), unless I've misunderstood something (not being anywhere near an expert on this topic, this is quite possible — even likely). Afterwards, it cites 5869 in such a way that sounds like it's saying that it's a subset of the approved algorithm (although "a version" is vague and confusing): > [RFC 5869] specifies a version of the above extraction-then-expansion > key-derivation procedure using HMAC for both the extraction and > expansion steps. For an extensive discussion concerning the rationale > for the extract-and-expand mechanisms specified in this > Recommendation, see [LNCS 6223]. The last citation in that paragraph to LNCS 6223 appears to give a long justification for why HKDF is secure, which all together makes it sound like HKDF is an approved algorithm and thus TLS 1.3 will be okay. —Sam -- Sam Whited ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Export Channel Binding
On Mon, May 4, 2020, at 11:44, Alexey Melnikov wrote: > In the Introduction of your draft you are referencing RFC 5705, which > can't be used with TLS 1.3. Instead you should reference Section 7.5 > of RFC 8446. Fixed on my local copy [1]. Thanks for your feedback! —Sam [1]: https://rfcs.samwhited.com/draft-whited-tls-channel-bindings-for-tls13-02.html ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Export Channel Binding
On Mon, May 4, 2020, at 09:14, Jonathan Hoyland wrote: > I've only skimmed the SCRAM RFC, but it might make sense to include > `client-first-message` and `server-first-message` as context to the > exporter interface, because it seems that the channel binding isn't > needed until the `client-final-message`. The idea is to use the > transcript to bind the channel binding to the negotiation of SCRAM > parameters, and thus allow you to define a single "TLS-SASL-SCRAM" > string (or whatever makes sense), rather than have one for each > possible set of parameters. Obviously you'd need to think some more > about whether that was actually secure, but at first glance it seems > like a reasonable approach. I had originally written a long-ish reply about why we couldn't make this SCRAM specific, but I've just realized after going back and looking at the spec and one of my own implementations that I was completely wrong. This is a great idea, and I believe would be secure since the client-first- message and server-first-message will contain their respective random nonces. A malicious client or server *could* slip some arbitrary text into either message, but if I understand TLS exporters security properties correctly this should not pose a problem and the export data should still be indistinguishable from random noise to someone without the TLS master secret (a sanity check by an expert on this statement would be appreciated). I have updated the draft with these changes: https://datatracker.ietf.org/doc/draft-whited-tls-channel-bindings-for-tls13/ I'm still not entirely clear if this would be a better draft for the KITTEN WG or this one. If we update the SCRAM RFCs I think it may be better to go through KITTEN, but I'm not sure that they'll want to take that work on. I'll ask. Any advice here would be appreciated since I know almost nothing about IETF policy or procedures. Thanks for your feedback! —Sam ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Export Channel Binding
On Fri, May 1, 2020, at 14:08, Jonathan Hoyland wrote: > Maybe I'm missing something, but I don't see what your draft adds? If > someone wants to construct a channel binding then they agree with > their peer on a context and a label, and use that to construct an > exporter key. The draft just registers a method of using it with the IANA Channel Binding Types registry so that you can negotiate and use exported keying material in eg. SCRAM based SASL auth. Right now if I wanted to use EKM for channel binding, what would I negotiate (ie. what would I set the p field of a gs2 header to in SASL based auth?) > Is the idea to reserve the string for some specific use? If so, then > the suggested string is far to general, as it describes _any_ use of > the interface. Yes, that's the idea. This registers the "tls-exporter" channel binding type in the registry, and the label EXPORTER-Channel-Binding to use with it. This is supposed to be a generic channel binding type that can be used to negotiate channel binding when multiple are available, eg. if the server supports both tls-unique (the last TLS finished message) and exporter data, we need an identifier to decide that we want to use exporter data. That also means having a label that we can associate with this context. I'd be happy to change the name if the consensus is that this is too general, but I didn't think it made sense to make this SASL or specific. —Sam ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Export Channel Binding
Hi Jonathan, On Fri, May 1, 2020, at 12:00, Jonathan Hoyland wrote: > I believe TLS Exporters are what you are looking for. > https://www.rfc-editor.org/rfc/rfc8446.html#section-7.5 Thanks for the follow up. That is indeed what the channel binding type I've created uses. Would the TLS working group be interested in standardizing such a document? I've gone ahead and uploaded my initial draft that I threw together here in case you're interested: https://datatracker.ietf.org/doc/draft-whited-tls-channel-bindings-for-tls13/ —Sam ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS Export Channel Binding
Hi all, I'm in need of a channel binding mechanism that works for TLS 1.3, but as far as I can tell there isn't one. I've thrown together a document defining a mechanism using RFC 5705 which I believe meets all of the requirements for good channel binding. Is anyone aware of work already being done in this area (I saw the token binding stuff, but that's a lot more complicated and browser-focused than a simple channel binding mechanism and work appears to have stalled), and if not would the TLS WG be interested in such a document? Thanks, Sam P.S. Note that I also sent this question to the KITTEN WG because I wasn't sure where this would belong. -- Sam Whited ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
