[kitten] TLS export for channel binding

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[kitten] TLS export for channel binding

Sam Whited
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
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] TLS export for channel binding

Sam Whited
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 [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten
>

--
Sam Whited

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] TLS export for channel binding

Alexey Melnikov
Hi Sam,

On 04/05/2020 19:14, Sam Whited wrote:

> 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?

I am happy to work on either one.

Best Regards,
Alexey


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] TLS export for channel binding

Benjamin Kaduk-2
On Mon, May 04, 2020 at 07:50:15PM +0100, Alexey Melnikov wrote:

> Hi Sam,
>
> On 04/05/2020 19:14, Sam Whited wrote:
> > 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?
>
> I am happy to work on either one.

Me, too (no hats).

-Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] TLS export for channel binding

Sam Whited
In reply to this post by Alexey Melnikov
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

On Mon, May 4, 2020, at 14:50, Alexey Melnikov wrote:
> I am happy to work on either one.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] TLS export for channel binding

Robbie Harwood
"Sam Whited" <[hidden email]> writes:

> 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)!

(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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] TLS export for channel binding

Sam Whited
On Thu, May 7, 2020, at 12:04, Robbie Harwood wrote:
> (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.

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] TLS export for channel binding

t.p.
In reply to this post by Robbie Harwood
----- Original Message -----
From: Robbie Harwood [hidden email]
Sent: 07/05/2020 17:04:35

"Sam Whited" <[hidden email]> writes:

> 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)!

(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.

<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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] TLS export for channel binding

Sam Whited
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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] TLS export for channel binding

Alexey Melnikov
Hi Sam,

On 08/05/2020 16:50, Sam Whited wrote:

> 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?

Not really, no.

> 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.

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] TLS export for channel binding

t.p.
In reply to this post by Sam Whited
---- Original Message -----
From: Sam Whited [hidden email]
Sent: 08/05/2020 16:50:14


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?

<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

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


Thanks for the feedback!

—Sam

--
Sam Whited

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] TLS export for channel binding

Alexey Melnikov
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.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] TLS export for channel binding

Robbie Harwood
In reply to this post by Sam Whited
"Sam Whited" <[hidden email]> writes:

> On Thu, May 7, 2020, at 12:04, Robbie Harwood wrote:
>
>> (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.
>
> 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.
To provide an update here: conversation with TLS is ongoing and we are
waiting to hear back at this time.

Thanks,
--Robbie

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] TLS export for channel binding

Robbie Harwood
Robbie Harwood <[hidden email]> writes:

> Sam Whited writes:
>> Robbie Harwood wrote:
>>
>>> (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.
>>
>> 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.
>
> To provide an update here: conversation with TLS is ongoing and we are
> waiting to hear back at this time.
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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] TLS export for channel binding

Sam Whited
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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] TLS export for channel binding

Sam Whited
Gentle ping. Is this something the WG would also be interested
in? Thanks.

—Sam

On Thu, May 21, 2020, at 19:02, Sam Whited wrote:

> 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
>
> _______________________________________________
> Kitten mailing list [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten
>

--
Sam Whited

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten