Re: [TLS] Require deterministic ECDSA

[Michael StJohns]

On 1/25/2016 7:41 PM, Bill Cox wrote:
I have low expectations for IoT vendors' TRNGs.  When deadlines get 
tight, good engineering on the TRNG is easy to drop.  As long as they 
whiten the output, it is very difficult to detect TRNG flaws, so there 
is little incentive to put in much engineering.  IIRC, the FIPS 
standard requires vendors to be secretive about their TRNGs.  They are 
not allowed to give us access to the raw data from the entropy source, 
and cannot show us schematics for their design, making it nearly 
impossible to differentiate a well designed TRNG from an insecure one.



Sorry for the late response on this one...

You should take a quick look at NIST Draft SP800-90B, section 7.1 
regarding how to do validation on entropy sources.While this is 
still in draft form and doesn't yet trigger requirements in the FIPS 
validation process, I would expect it will at some point.   I would also 
expect that new designers are probably making sure that this type of 
interface is included in their products - to at least allow for the 
possibility of validation.


Of course, if an IoT vendor isn't looking for FIPS validation (or some 
other such process that requires at least a little testing), all bets 
are off.


Later, Mike

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

[David Benjamin]

On Mon, Jan 11, 2016 at 6:17 PM David Benjamin 
wrote:

> In terms of getting rid of TLS 1.0 and TLS 1.1 altogether, we're seeing
> around 3% of connections using TLS 1.0 or TLS 1.1. That's quite high, and
> it's likely that enterprise deployments are much worse.
>
> I started gathering numbers on ServerKeyExchange hashes back in November.
> The code isn't on Chrome's stable channel yet, but earlier channels say a
> bit over 5% of ServerKeyExchanges are signed with SHA-1, which is also
> quite high.
>
> I also started probing servers in November and observed:
> (a) Servers which always sign SHA-1.
>

Lest anyone get their hopes up, it turns out OpenSSL-based servers before
1.0.1j that use SNI (specifically those that call SSL_set_SSL_CTX in the
SNI callback) ignore the signature_algorithms extension and only sign
SHA-1. We'll be stuck with this one for a long while. 1.0.1j was only
released 2014-10-15, and Linux distributions tend to be on older versions
with backported security fixes to say nothing of folks that don't update at
all.
https://rt.openssl.org/Ticket/Display.html?id=3560

David


> (b) Servers which sign SHA-1 *unless* signature_algorithms omits it. Then
> they sign SHA-256!?!!?
> (c) Servers which sign SHA-2 but fail if signature_algorithms omits SHA-1.
> The ones I looked at were all from serving SHA-1 certificates, so probably
> their SSL stack compares certs against sig_algs.
>
> (b) and (c) mean that getting a sense of the true impact will be
> complicated until we finish getting SHA-1 certificates out of our system. I
> have not dug into what's going on with groups (a) and (b) yet.
>
> This all is not to say we shouldn't phase these out. But I do not expect
> it to be a speedy process for browsers.
>
> David
>
> On Mon, Jan 11, 2016 at 1:30 PM Kurt Roeckx  wrote:
>
>> Hi,
>>
>> After the SLOTH paper, we should think about starting to deprecate
>> TLS 1.0 and TLS 1.1 and the SHA1 based signature algorithms in TLS
>> 1.2.
>>
>> As I understand it, they estimate that both TLS 1.2 with SHA1 and
>> TLS 1.0 and 1.1 with MD5|SHA1 currently require about 2^77 to be
>> broken.  They all depend on the chosen prefix collision on SHA1,
>> with the MD5 part in TLS 1.0 and 1.1 not adding much.
>>
>> It seems that disabling SHA1 in TLS 1.2 doesn't buy you anything
>> unless you also disable TLS 1.0 and 1.1.
>>
>>
>> Kurt
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls