On Sunday 24 January 2016 02:04:28 Dave Garrett wrote:
> On Saturday, January 23, 2016 07:47:11 pm Michael StJohns wrote:
> > 1) A receiver of an deterministic ECDSA signature verifies it
> > EXACTLY
> > like they would a non-deterministic signature.
> > 2) A receiver of an ECDSA signature cannot d
The main argument I see from the RFC for deterministic ECDSA is computing k
on systems without high quality entropy sources. But any system running a
TLS stack is already going to have a high quality entropy source for
client/server randoms and IVs and such, so what's the benefit of
deterministic E
> But any system running a TLS stack is already going to have a high quality
> entropy source for client/server randoms and IVs and such
That's assuming a constraint that isn't accurate.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/lis
On Sat, Jan 23, 2016 at 9:20 PM, Brian Smith wrote:
>> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA.
>
> What about the way BoringSSL (and OpenSSL, I think) does it? It incorporates
> all the inputs that RFC6979 does, but using SHA-512 instead of HMAC. And, it
> also includ
On 01/22/2016 01:14 PM, Hubert Kario wrote:
> On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote:
>> On 01/22/2016 03:14 AM, Hubert Kario wrote:
The only solution that's available at this point is conditioning
TLS
1.3 support on appropriate hardware. For this reason TLS 1.3 it
>>
This is a draft that might be of some interest to the mailing list, but please
send your comments to the DPRIVE mailing list.
spt
> -- Forwarded message -
> From: Tim Wicinski mailto:tjw.i...@gmail.com>>
> Date: Tue, Jan 12, 2016 at 4:56 PM
> Subject: [dns-privacy] Call for Adopt
All,
Andrey sent this message at the chairs' request to make sure that we adequately
discussed the issue, which we discussed at the last IETF meeting
(https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf).
spt
> On Jan 21, 2016, at 21:25, Andrey Jivsov wrote:
>
> Current draft of T
Sorry, I'd meant to add this note to the message below and forgot:
In putting together the PR, I noticed that eddsa is currently in the draft
as always paired with no hash rather than the one it uses internally. So
the problem about advertising {sha512, eddsa} and eddsa_448 doesn't occur.
My bad,
> On 25 Jan 2016, at 5:08 PM, Salz, Rich wrote:
>
>> But any system running a TLS stack is already going to have a high quality
>> entropy source for client/server randoms and IVs and such
>
> That's assuming a constraint that isn't accurate.
Eh. Just s/is/should/
__
> is/should, or they're going to have other problems.
Really?
Some high-value device that is rarely connected-to? Like a missle?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Mon 2016-01-25 14:10:13 -0500, Yoav Nir wrote:
>> On 25 Jan 2016, at 5:08 PM, Salz, Rich wrote:
>>
>>> But any system running a TLS stack is already going to have a high quality
>>> entropy source for client/server randoms and IVs and such
>>
>> That's assuming a constraint that isn't accura
On Monday 25 January 2016 10:29:18 Benjamin Kaduk wrote:
> On 01/22/2016 01:14 PM, Hubert Kario wrote:
> > On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote:
> >> On 01/22/2016 03:14 AM, Hubert Kario wrote:
> The only solution that's available at this point is conditioning
> TLS
> >>
Thanks for the discussion so far on this.
I've closed PR 406; it is replaced by:
https://github.com/tlswg/tls13-spec/pull/408
to wit:
- ECDSA details para says RFC6979 is RECOMMENDED (I've tried to keep
this part succinct, but I think it fits next to the X9.62 reference).
- Crypto pitfalls sect
On Mon, Jan 25, 2016 at 11:25 AM, Salz, Rich wrote:
>> is/should, or they're going to have other problems.
>
> Really?
>
> Some high-value device that is rarely connected-to? Like a missle?
If you can't generate 256 random bits for use as a DH key or a client
random, anyone can read the connecti
And your lightbulb maker? Or your stove maker? Or your fridge? All on coming
IoT?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
is/should, or they're going to have other problems.
-Jake M
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
OK We'll ask for early code point assignment for
ecdh_x25519 (29), ecdh_x448 (30)
On Tue, Jan 19, 2016 at 10:59 AM, Andrei Popov
wrote:
> Yes, please allocate, esp. 25519. MS will start testing interop soon.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On B
On Jan 25, 2016, at 2:43 PM, Hubert Kario wrote:
> On Monday 25 January 2016 10:29:18 Benjamin Kaduk wrote:
>> On 01/22/2016 01:14 PM, Hubert Kario wrote:
>>> On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote:
On 01/22/2016 03:14 AM, Hubert Kario wrote:
>> The only solution that's a
On 01/25/2016 03:11 PM, Russ Housley wrote:
On Jan 25, 2016, at 2:43 PM, Hubert Kario wrote:
On Monday 25 January 2016 10:29:18 Benjamin Kaduk wrote:
On 01/22/2016 01:14 PM, Hubert Kario wrote:
On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote:
On 01/22/2016 03:14 AM, Hubert Kario wrote
19 matches
Mail list logo
