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
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 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 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
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 prescribing behavior,
> particularly of the state machine. This draft does not
On Mon, Oct 31, 2016 at 11:41:46AM -0700, Watson Ladd wrote:
> ECDSA cannot be used with x25519 or x448, but the draft seems to
> require support in TLS 1.2 for this as a consequence of its
> description of the fallback mode. The mandated use of uncompressed
> points invites easy wrong-curve attac
