Thanks, Alessandro! We'll aim to merge this PR on Friday. We ask that folks
review it before then.
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/5
Thanks,
Chris, on behalf of the chairs
On Thu, Apr 23, 2020, at 10:45 AM, Alessandro Ghedini wrote:
> On Sun, Nov 24, 2019 at
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, and
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.samwhi
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 refe
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 here
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 fo
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-m
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 different
