Subject: Re: [kitten] TLS export for channel binding

From: "Sam Whited" <[email-masked]>
Date: Mon, 04 May 2020 14:14:09 -0400

Hi again all,

I submitted this idea as a draft to the TLS working group. However, the
draft ended up becoming SCRAM/TLS 1.3 specific and the TLS WG suggested
that it might be a better fit for KITTEN, either as an update to RFC
5802, or as a new I-D.

Would this WG be interested in either the draft document or starting an
update to RFC 5802 if the TLS WG decides that the draft is outside of
their wheelhouse?

Thanks,
Sam

On Thu, Apr 30, 2020, at 16:02, Sam Whited wrote:
> 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 was thinking about defining a
> mechanism using RFC 5705 (which is updated by RFC 8446 so it should
> work on both TLS 1.2 with appropriate cipher suites and 1.3 in
> general).
>
> Is anyone aware of work already being done in this area, and if I were
> to define a mechanism would it be a better fit for this working group
> or for the tls WG?
>
> I know that exporters have some caveats around how to ensure
> uniqueness across different sessions, so this would likely require a
> great deal of expert review if it's a feasible mechanism at all and I
> wasn't sure where the best place to get that review would be.
>
> —Sam
>
> Thanks, Sam
>
> _______________________________________________
> Kitten mailing list [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

-- 
Sam Whited

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 4 May 2020 19:50:15 +0100

Hi Sam,

> update to RFC 5802 if the TLS WG decides that the draft is outside of

I am happy to work on either one.

Best Regards,
Alexey

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 5 May 2020 15:44:24 -0700

> I am happy to work on either one.

Me, too (no hats).

-Ben

---

From: "Sam Whited" <[email-masked]>
Date: Wed, 06 May 2020 13:26:25 -0400

Sounds good. There's been more interest here, so would the next step be
for me to change the draft from "draft-whited-tls" to "draft-whited-
kitten" ? If so I'll move it over and reset the version to 0.

Thanks for your help as I try to understand this process (again)!

—Sam

---

From: Robbie Harwood <[email-masked]>
Date: Thu, 07 May 2020 12:04:35 -0400

> Thanks for your help as I try to understand this process (again)!

(Chair/obnoxious process hat on) I think it would be best to have a
formalized call for adoption in kitten - that's a separate email with
"call for adoption" and the thing to adopt in the subject.  What I've
observed so far is interest in the document existing (and willingness to
work on it), but not specifically in kitten.  We'll let that simmer
about a week, and then if there's consensus, we can adopt.

(As a contributor) I've certainly no objections to adoption, but TLS is
not exactly my wheelhouse.

Thanks,
--Robbie

---

From: "Sam Whited" <[email-masked]>
Date: Thu, 07 May 2020 12:40:44 -0400

On Thu, May 7, 2020, at 12:04, Robbie Harwood wrote:
> observed so far is interest in the document existing (and willingness
> to work on it), but not specifically in kitten.  We'll let that simmer

Thanks for your help. Is that an email I should send when I figure out
whether this belongs in TLS or KITTEN, or should I ask someone else to
issue the call, perhaps the chair?

Today I've been thinking that this really depends on whether the draft
is SCRAM specific or not. If it is, this might be a better place to take
on the work, if not, the TLS WG might be better. Although if it's not
SCRAM specific it probably doesn't matter where it lives because the I-D
becomes almost trivial, it's just instructions for IANA to register two
labels in a registry so that the existing TLS channel binding mechanism
can be used from SASL.

—Sam

-- 
Sam Whited

---

From: "tom petch" <[email-masked]>
Date: Fri, 8 May 2020 16:41:17 +0100

----- Original Message -----
From: Robbie Harwood [email-masked]
Sent: 07/05/2020 17:04:35

<tp>
which I think is the problem; whose is? The I-D baldly states that the current channel binding does not work with TLS 1.3, with no explanation.  I track the TLS list and do not recall the discussion but the development of 1.3 was tortuous and I could have skipped the discussion on the grounds of This Is One More 1.3 Problem I Could Do Without.  Whatever, this I-D needs to spell the problem out and IMHO update the current RFC on TLS Channel Binding so that others can see that there is a problem.   There is a lot of expertise on the TLS list whose names I know well and trust but I do not see many of them posting here.  Which pushes me to thinking that this I-D 

---
New Outlook Express and Windows Live Mail replacement - get it here:
https://www.oeclassic.com/

belongs elsewhere.
Tom Petch

Thanks,
--Robbie

---

From: "Sam Whited" <[email-masked]>
Date: Fri, 08 May 2020 11:50:14 -0400

On Fri, May 8, 2020, at 11:41, tom petch wrote:
> which I think is the problem; whose is? The I-D baldly states that the
> current channel binding does not work with TLS 1.3, with no
> explanation.

I'll fix that, thanks!

> Whatever, this I-D needs to spell the problem out and IMHO update the
> current RFC on TLS Channel Binding so that others can see that there
> is a problem.

Is there a different process to update an existing RFC vs. creating a
new I-D and trying to get it adopted by a WG? I'm still unclear on the
process in general, and it seems like this might be different.

If we're updating that document anyways, I assume the TLS WG would be
the place and we might as well integrate this I-D into the document
update instead of keeping it a separate I-D.

> Which pushes me to thinking that this I-D

Looks like this got cut off?

Thanks for the feedback!

—Sam

-- 
Sam Whited

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 8 May 2020 17:11:07 +0100

Hi Sam,

On 08/05/2020 16:50, Sam Whited wrote:
> new I-D and trying to get it adopted by a WG?

Not really, no.

> I'm still unclear on the

I don't think we should revise RFC 5056, adding a new channel binding in
a new draft would be easier. RFC 5056 already created a registry for
channel bingings:

https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml

So we can just add a new registration.

Best Regards,
Alexey

---

From: "tom petch" <[email-masked]>
Date: Fri, 8 May 2020 17:13:37 +0100

---- Original Message -----
From: Sam Whited [email-masked]
Sent: 08/05/2020 16:50:14

I'll fix that, thanks!

<tp>
No, my antisocial MUA put an advertisement in the middle of the sentence, which it will probably do here as well.  RFC are never changed, once issued that is it (which I like - contrast IEEE). So when technology advances, we can issue a -bis, a new RFC number, which is a total replacement; or we can issue a new RFC which is an update to the old adding new information, obsoleting the out-of-date and so on.  The RFC Index on the RFC Editor website lists everything that updates or obsoletes everything else as well as saying which are Standards, Standards Track, Historic and so on; I notice that yours is Experimental which is let's give this a go and see what happens and may be later it can become a Standard but in the meantime don't rely on it too much.  All IETF work starts as an I-D and may go through dozens of iterations before advancing; most are adopted by a Working Group, with WG Chairs, AD and so on, with the expertise to peer review and get it to a stage worthy of publication.  It can be a challenge to get it adopted - some WG seem reluctant (TLS comes to mind not that TLS does not do a lot of work or perhaps that is why).  Adoption is controlled by the WG Chair but depends on support from WG members.  For this I-D, of the WG I track, my sense is that the TLS WG has the skills to review this and Kitten may not (duck, as the brickbats come in).  I was involved in the early stages on channel binding in the IETF and have kept on looking at it and wondering why such a good idea is not more widely used.
Tom Petch

---

Thanks for the feedback!

—Sam

-- 
Sam Whited

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 9 May 2020 12:48:13 +0100

On 08/05/2020 17:13, tom petch wrote:

> For this I-D, of the WG I track, my sense is that the TLS WG has the skills to review this and Kitten may not (duck, as the brickbats come in).

Yeah, I think I disagree with this statement. I think either WG has 
expertese to review it, but some collaboration (crossposting might be 
enough) is needed anyway.

---

From: Robbie Harwood <[email-masked]>
Date: Tue, 12 May 2020 15:53:03 -0400

"Sam Whited" <[email-masked]> writes:

>> to work on it), but not specifically in kitten.  We'll let that
>> simmer about a week, and then if there's consensus, we can adopt.
>
> is SCRAM specific or not. If it is, this might be a better place to
> take on the work, if not, the TLS WG might be better. Although if it's
> not SCRAM specific it probably doesn't matter where it lives because
> the I-D becomes almost trivial, it's just instructions for IANA to
> register two labels in a registry so that the existing TLS channel
> binding mechanism can be used from SASL.

To provide an update here: conversation with TLS is ongoing and we are
waiting to hear back at this time.

Thanks,
--Robbie

---

From: Robbie Harwood <[email-masked]>
Date: Thu, 21 May 2020 19:00:07 -0400

Robbie Harwood <[email-masked]> writes:

> Sam Whited writes:
>> Robbie Harwood wrote:
>>> formalized call for adoption in kitten - that's a separate email
>>> with "call for adoption" and the thing to adopt in the subject.
>>> What I've observed so far is interest in the document existing (and
>>> willingness to work on it), but not specifically in kitten.  We'll
>>> let that simmer about a week, and then if there's consensus, we can
>>> adopt.
>>
>> Thanks for your help. Is that an email I should send when I figure
>> out whether this belongs in TLS or KITTEN, or should I ask someone
>> else to issue the call, perhaps the chair?
>>
>> Today I've been thinking that this really depends on whether the
>> draft is SCRAM specific or not. If it is, this might be a better
>> place to take on the work, if not, the TLS WG might be
>> better. Although if it's not SCRAM specific it probably doesn't
>> matter where it lives because the I-D becomes almost trivial, it's
>> just instructions for IANA to register two labels in a registry so
>> that the existing TLS channel binding mechanism can be used from
>> SASL.
>

Consensus from the TLS chairs seems to be a preference for work to occur
in Kitten, though we should make sure that TLS folks review it.

Thanks,
--Robbie

---

From: "Sam Whited" <[email-masked]>
Date: Thu, 21 May 2020 19:02:06 -0400

On Thu, May 21, 2020, at 19:00, Robbie Harwood wrote:
> Consensus from the TLS chairs seems to be a preference for work to
> occur in Kitten, though we should make sure that TLS folks review it.

This works for me. Would you be willing to issue a formal call for
adoption on this one as well Robbie?

Thanks!

—Sam

-- 
Sam Whited