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
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
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
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
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
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
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 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
> >>
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
> 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 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/
__
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,
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
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
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
>>
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
> 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
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
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
19 matches
Mail list logo
