Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-kitten-tls-channel-bindings-for-tls13-09.txt> (Channel Bindings for TLS 1.3) to Proposed Standard

Hi Sam, all,

I'd like to again raise the issues I pointed out in
https://mailarchive.ietf.org/arch/msg/kitten/13pPj4E3-gYwpbu2K844uI1BPoU/ .
This draft hasn't received enough security analysis, and further, I pointed
out a specific security issue that remains unaddressed.

Using the same label for different protocols produces trivial collisions,
and thus it is perfectly possible that a message meant for GSS-API is
identical in both form and key to a message for SCRAM, and thus there is
strong potential for confusion.
I'm not familiar with either of these protocols, so maybe they have
internal reasons why this example doesn't work, but that misses the much
larger and more significant point.
Any future protocol that uses the same label will potentially be
confusable, and further updates to GSS-API now must ensure that they don't
form valid SCRAM 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."

The correct solution would be to use unique labels for every different mode
and variant of SCRAM and GSS-API, and require this for all runs, and
further include a run number in the label derivation.
This string can be (should be) constructed mechanistically, and commit the
TLS client and TLS server to all relevant security parameters.

Another approach would be to use a fixed string to generate a channel
binding, use that in a run of GSS-API, and then call the Exporter API again
on the hash of the transcript and any relevant key material*.
Taking the resultant output and HKDFing it with the keys resulting from the
GSS-API run would give you a channel binding that is unique for every
unique run of GSS-API.
This is a much stronger binding, tying the specific run of the GSS-API back
to the TLS layer. The idea being that even in the case that the TLS
server's private key has been compromised, if the GSS-API run was secure
then the TLS layer was run honestly (i.e. is with the server.)

Regards,

Jonathan

* Specifically everything listed in Verified Contributive Channel Bindings
for Compound Authentication
<https://www.ndss-symposium.org/wp-content/uploads/2017/09/08_5.pdf>
Section II should be included.

On Mon, 4 Oct 2021 at 01:32, Sam Whited <sam@samwhited.com> wrote:

> 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 <future RFC number>".
>
> 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
>