Hi all,
After thinking about this a little more, I think we should keep the
draft generic and not make it SCRAM specific. While I generally agree
with Jonathan's defense-in-depth strategy, there is also value in having
a direct replacement for tls-unique that can be substituted in
everywhere
Hi Alexey
On Mon, 4 May 2020 at 16:23, Alexey Melnikov
wrote:
> Hi Jonathan,
>
> On 04/05/2020 14:14, Jonathan Hoyland wrote:
> > Hi Sam,
> >
> > If you wanted to use a SCRAM based SASL auth then you could pick
> > `p=SCRAM-SHA256-PLUS`, or any other very specific IANA-registered
> > string,
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]:
Hi Sam,
On 04/05/2020 15:39, Sam Whited wrote:
I have updated the draft with these changes:
https://datatracker.ietf.org/doc/draft-whited-tls-channel-bindings-for-tls13/
In the Introduction of your draft you are referencing RFC 5705, which
can't be used with TLS 1.3. Instead you should
Hi Sam,
On 04/05/2020 15:39, Sam Whited wrote:
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
Hi Jonathan,
On 04/05/2020 14:14, Jonathan Hoyland wrote:
Hi Sam,
If you wanted to use a SCRAM based SASL auth then you could pick
`p=SCRAM-SHA256-PLUS`, or any other very specific IANA-registered
string, and update the SCRAM RFC to require that string with TLS 1.3.
You actively don't want
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
Hi Sam,
If you wanted to use a SCRAM based SASL auth then you could pick
`p=SCRAM-SHA256-PLUS`, or any other very specific IANA-registered
string, and update the SCRAM RFC to require that string with TLS 1.3.
You actively don't want for the same channel binding to be an input to
multiple
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
Hi Sam,
I think the idea is that any unique¹ exporter _is_ an RFC
5056-compliant channel binding.
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
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
Hi Sam,
I believe TLS Exporters are what you are looking for.
https://www.rfc-editor.org/rfc/rfc8446.html#section-7.5
Exporters allow you to produce a key that is a bound to a particular
channel i.e. TLS session.
Regards,
Jonathan
On Fri, 1 May 2020 at 15:13, Sam Whited wrote:
> Hi all,
>
>
12 matches
Mail list logo
