I'm confused by the line "These messages are not encrypted", because on a
plain reading it could mean that the authenticator is sent outside the
encrypted TLS session. That would be bad because it would mean that clients
that wanted to authenticate themselves but to the server only wouldn't be
able
On Mon, Oct 31, 2016 at 2:28 PM, Eric Rescorla wrote:
> Watson,
>
> Thanks for your comments!
>
> On Mon, Oct 31, 2016 at 11:41 AM, Watson Ladd wrote:
>>
>> Hello,
>>
>> Looking at the history of TLS implementation attacks we see that many
>> result from the standard not strictly enough prescribi
Yes, this line has confused me as well.
Cheers,
Andrei
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of William Whyte
Sent: Tuesday, November 1, 2016 1:42 AM
To: Nick Sullivan
Cc: tls@ietf.org
Subject: Re: [TLS] draft-sullivan-tls-exported-authenticator-00
I'm confused by the line "These m
On Tue, Nov 01, 2016 at 04:41:44AM -0400, William Whyte wrote:
> I'm confused by the line "These messages are not encrypted", because on a
> plain reading it could mean that the authenticator is sent outside the
> encrypted TLS session. That would be bad because it would mean that clients
> that wa
That makes sense, but it'd be good to clarify the text. Thanks!
William
-- sent from my phone
On Nov 1, 2016 11:57 AM, "Ilari Liusvaara" wrote:
> On Tue, Nov 01, 2016 at 04:41:44AM -0400, William Whyte wrote:
> > I'm confused by the line "These messages are not encrypted", because on a
> > pla
On 2 November 2016 at 02:45, Watson Ladd wrote:
>
> That sounds good. The more we can turn bugs into ones that violate the
> spec, the easier it will be to get them fixed. (Hopefully)
failure to interoperate >> violate the spec
I know that NSS rejects multiple HRRs. I expect that Boring does to
On Tue, Nov 1, 2016 at 9:30 PM, Martin Thomson wrote:
> On 2 November 2016 at 02:45, Watson Ladd wrote:
>>
>> That sounds good. The more we can turn bugs into ones that violate the
>> spec, the easier it will be to get them fixed. (Hopefully)
>
> failure to interoperate >> violate the spec
>
> I
On 2 November 2016 at 15:57, Watson Ladd wrote:
> A conforming client will not produce Client Hellos that trigger
> multiple HRRs: it will listen the first time.
Good point. And most clients will elicit none. I don't know how to
force this one into a failure to interoperate without taking the
ap
