Hello TLSWG and IESG reviewers,
This is a compendium of responses to the various reviews of the document.
There are a few remaining open questions to address that I hope we can
resolve in this thread.
I’ve compiled the changes to the document in response to the comments in
Github:
https://github
Ben,
Putting the authenticator in an encrypted tunnel is not necessary for
binding, but it is necessary for keeping the certificate itself
confidential. I'll add text to that effect.
Nick
On Wed, Nov 15, 2017 at 7:13 PM Benjamin Kaduk wrote:
> In the exported authenticators draft we claim that
In the exported authenticators draft we claim that "The
application layer protocol used to send the authenticator SHOULD
use TLS as its underlying transport." This is of course natural --
why would you be using TLS authenticators if you were not using TLS
-- but it seems that we would also benefit
On 22 July 2017 at 07:42, Watson Ladd wrote:
>> If crc is repeated within a connection, then the old certificate
>> message can be replayed.
>>
>> If crc is guessed, then reply can be pregenerated anytime during
>> connection.
>>
>> However, neither seems crticial, but might be of magnitude to not
On Fri, Jul 21, 2017 at 10:34 PM, Ilari Liusvaara
wrote:
> On Fri, Jul 21, 2017 at 10:17:08PM -0700, Watson Ladd wrote:
>> On Fri, Jul 21, 2017 at 12:55 PM, Benjamin Kaduk wrote:
>> > Unrelated to Ilari's questions, I wonder if we want to say anything about
>> > certificate_request_context values
On Fri, Jul 21, 2017 at 10:17:08PM -0700, Watson Ladd wrote:
> On Fri, Jul 21, 2017 at 12:55 PM, Benjamin Kaduk wrote:
> > Unrelated to Ilari's questions, I wonder if we want to say anything about
> > certificate_request_context values being unique across both in-TLS
> > post-handshake auth and ex
On Fri, Jul 21, 2017 at 12:55 PM, Benjamin Kaduk wrote:
> Unrelated to Ilari's questions, I wonder if we want to say anything about
> certificate_request_context values being unique across both in-TLS
> post-handshake auth and exported authenticators.
This context is not a security sensitive thin
Unrelated to Ilari's questions, I wonder if we want to say anything
about certificate_request_context values being unique across both in-TLS
post-handshake auth and exported authenticators.
-Ben
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mail
On Thu, Jul 20, 2017 at 12:02 AM, Ilari Liusvaara
wrote:
> While reading/implementing draft-ietf-tls-exported-authenticator I came
> across the following:
>
> 1)
>
> The exporter labels are the opposite way around for handshake
> contexts and finished keys, which makes little sense.
>
> The text
While reading/implementing draft-ietf-tls-exported-authenticator I came
across the following:
1)
The exporter labels are the opposite way around for handshake
contexts and finished keys, which makes little sense.
The text seems to imply that the finished key label the client
uses for sending is
10 matches
Mail list logo
