Just to clarify, I think it is fine to define TLS 1.3 replacement for
tls-unique using Exporters. But I suggest for interoperability this should be
defined as a new channel binding with a new name, as opposed to just redefining
tls-unique.
___
TLS mail
TLS 1.2 and 1.3. I think
the best way would be to take Simon's draft-josefsson-sasl-tls-cb-03
(Channel Bindings for TLS based on the PRF) and update it for TLS 1.3. I
think conceptually what Simon did is very similar to what was proposed
in the TLS meeting today.
> -Ekr
>
>
> On
can't redefine how tls-unique works for TLS 1.2 without breaking
existing implementations (I can explain this in more details, if needed).
All of these made me think that defining a new channel binding that
works for both TLS 1.2 and TLS 1.3 would be a better option.
> On 4 November 2015 at 1
> On 12 Jan 2016, at 21:31, Ilari Liusvaara wrote:
>
>> On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote:
>>
>>> On 12 Jan 2016, at 9:26 PM, Simon Josefsson wrote:
>>>
>>> The same concern still applies: what does it mean to allocate code
>>> point for the 4492bis-05 description?
>>
Hi Jonathan,
On 05/11/2021 15:34, Jonathan Hoyland wrote:
Hi Simo,
As I said in my email to Sam, my language here was sloppy, I meant
that the channel binding is included in the key derivation process,
and thus the output keys will be related to each other.
The term channel bindings has two d
Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-dnssec-chain-extension-06: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-tls13-26: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
Hi Ekr,
On Wed, Mar 7, 2018, at 2:16 PM, Eric Rescorla wrote:
>
>
> On Wed, Mar 7, 2018 at 5:29 AM, Alexey Melnikov
> wrote:>> Alexey Melnikov has entered the following
> ballot position for
>> draft-ietf-tls-tls13-26: Discuss
>>
>> When responding,
Hi,
On Wed, Feb 21, 2018, at 4:06 PM, Shumon Huque wrote:
> On Wed, Feb 7, 2018 at 9:05 PM, Shumon Huque wrote:>> On
> Wed, Feb 7, 2018 at 1:22 PM, Alexey Melnikov
>> wrote:
>>> Alexey Melnikov has entered the following ballot position for
>>> draft-iet
Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-dnssec-chain-extension-07: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-iana-registry-updates-04: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however
, 2018 at 09:56:16AM -0700, Alexey Melnikov wrote:
> > Alexey Melnikov has entered the following ballot position for
> > draft-ietf-tls-iana-registry-updates-04: No Objection
> >
> > ---
sent
> out a PR to clarify that
> <https://github.com/tlswg/certificate-compression/pull/32/files>.
Great, thank you.
>
> On Mon, Dec 16, 2019 at 8:28 AM Alexey Melnikov via Datatracker
> wrote:
>> Alexey Melnikov has entered the following ballot position for
&g
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
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 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
Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-chacha20-poly1305-04: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
There is also RFC 4634, but I am not sure which reference is better.
> Regards,
> Quynh.
>
> From: TLS on behalf of Stephen Farrell
>
> Sent: Thursday, May 5, 2016 10:14:19 AM
> To: Alexey Melnikov; The IESG
> Cc: draft-ietf-tls
Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-rfc4492bis-15: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-grease-03: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-sni-encryption-06: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-certificate-compression-08: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however
22 matches
Mail list logo
