Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3

[Andrey Jivsov]

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:

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
probably won't be enabled by default in the product I work on. I
would prefer for TLS 1.3 to be enabled by default and write the
code
to decide whether it does PSS or falls back to RSA PKCS1 1.5.

Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not
cutting it off now would be negligent.

You mean for HS only, while leaving it for X.509 certs?

If we don't do it for HS in TLS first, we'll never get rid of it in
X.509 certs.

We need to start somewhere, and it's more reasonable to expect that
hardware with support for new protocols will get updated for RSA-PSS
handling than that libraries and hardware will suddenly start
implementing it in droves just in anticipation of the time when CAs
_maybe_ will start issuing certificates signed with RSA-PSS.

Isn't it more a matter of TLS being a consumer of external PKIX
infrastructure, the web PKI, etc.?  They are out of the reach of the
IETF TLS working group; any requirements we attempted to impose would
be unenforceable, even if there was an Internet Police (which there
is not).

TLS will happily use PKCS#1 v1.5 signed X.509 certificates, so how
exactly is creating a side effect of increasing the deployment rate of
RSA-PSS _in TLS implementations_ an "overreach"?!

I have been a supporter of PSS for a very long time -- see RFC 4055.

We have many algorithm transition issues, but this is one place where we have 
seen very little progress.  I would like to see support for PSS in the 
protocol, even if we need to support PKCS v1.5 for certificate signatures for a 
long time.


Is there evidence that hard-wiring {PSS} in HS and {PSS, PKCS#1 1.5} 
with X.509 certs will lead to better PSS adoption than if {PSS, PKCS#1 
1.5} were available in both HS and X.509 certs?


This should be balanced against the reality that PSS in HS with TLS 1.3 
guarantees lower TLS 1.3 adoption as I wrote above. PSS-only in TLS 1.3 
HS may make code more complex as well.


I am trying to imagine a logic that a TLS 1.3 client supporting 
smartcard client authentiation would need to implement, assuming 
mandatory PSS signing in HS, e.g. a case of Firefox + PKCS#11 interface 
with a smartcard.


First, the code should query (attached? logged-in?) smartcard(s) to 
determine if the key(s) on the smartcard that might be used for client 
authentication can do PSS signing. PKCS#11 interface lists the PSS 
capability as CKM_SHA256_RSA_PKCS_PSS mechanism. If no such PSS+hash 
mechanism is available, the code needs to tag the keys(s) as TLS 
1.2-only. When the client connects to a TLS 1.3 server and the server 
requests client authentication with the non-PSS key, I think this will 
require protocol dance down to TLS 1.2 (insecure TLS fallback). 
Alternatively, the client will need to start from TLS 1.2 when it 
detected such a smartcard, for any server.


The underlying reasons why CAs can't sign with PSS v.s. TLS server or 
client are probably overlapping in many cases: FIPS 140, HSM, hardware. 
The all-or-nothing approach to PSS sin HS eems inconsistent with 
traditional feature negotiation in TLS HS.



Russ


___
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

Re: [TLS] Require deterministic ECDSA

[Jacob Maskiewicz]

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 ECDSA here?

-Jake M
On Jan 23, 2016 11:13 AM, "Joseph Birr-Pixton"  wrote:

> Hi,
>
> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA.
>
> For discussion, here's a pull request with possible language:
>
> https://github.com/tlswg/tls13-spec/pull/406
>
> Cheers,
> Joe
>
> ___
> 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

Re: [TLS] Require deterministic ECDSA

[Adam Langley]

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 includes a random element in the SHA-512 hash.
>
> Ed25519 uses SHA-512 instead of HMAC for the same purpose and people seem to
> think it works fine.
>
> Also hashing in some randomness seems like it would help avoid some side
> channel leakage. Note that most (all the ones I've looked at for more than 5
> minutes) open-source ECDSA implementations have side-channel issues of
> various levels of significance.
>
> Anyway, I do think that implementations should do something *like this* to
> avoid problems when the RNG is bad, but I think prescribing RFC 6979 as the
> solution is overly-specific, especially when it doesn't even seem to be the
> best way to accomplish the goal in many cases.

I wrote that design before RFC6979 (or, at least, before I was aware
of it). The reason that I included randomness into the mix was because
I worried that someone might be depending on the randomised nature of
ECDSA signatures and suddenly making them deterministic seemed like a
risky thing to do. That's not a problem in TLS.

I think that those implementations that care about DPA-level
side-channel attacks will probably do their thing no matter what the
standard says, so I wouldn't have an objection to putting a "SHOULD"
in the spec for RFC 6979. I suspect that adherence would be poor,
however. As for using that RFC over what I came up with or anything
else: at least RFC 6979 has been written down already.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] Require deterministic ECDSA

[Salz, Rich]

> 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/listinfo/tls

Re: [TLS] Require deterministic ECDSA

[Joseph Birr-Pixton]

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 section has a new point with a little further
discussion, trying to impress upon the reader how badly this goes
wrong.

Cheers,
Joe

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

Re: [TLS] Require deterministic ECDSA

[Yoav Nir]

> 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/


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

Re: [TLS] Require deterministic ECDSA

[Watson Ladd]

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 connection if they know what the random
number generator actually produced. If you can produce 256 random
bits, and the device maker was halfway competent, they should know how
to turn 256 random bits into computationally indistinguishable
infinite stream of random bits. If your missile maker was not halfway
competent at computer security, I can only hope the guidance engineers
were of the same caliber.


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



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

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

Re: [TLS] Require deterministic ECDSA

[Salz, Rich]

> 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

Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3

[Benjamin Kaduk]

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
 probably won't be enabled by default in the product I work on. I
 would prefer for TLS 1.3 to be enabled by default and write the
 code
 to decide whether it does PSS or falls back to RSA PKCS1 1.5.
>>> Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not
>>> cutting it off now would be negligent.
>> You mean for HS only, while leaving it for X.509 certs?
> If we don't do it for HS in TLS first, we'll never get rid of it in 
> X.509 certs.
>
> We need to start somewhere, and it's more reasonable to expect that 
> hardware with support for new protocols will get updated for RSA-PSS 
> handling than that libraries and hardware will suddenly start 
> implementing it in droves just in anticipation of the time when CAs 
> _maybe_ will start issuing certificates signed with RSA-PSS.
>
>

Isn't it more a matter of TLS being a consumer of external PKIX
infrastructure, the web PKI, etc.?  They are out of the reach of the
IETF TLS working group; any requirements we attempted to impose would be
unenforceable, even if there was an Internet Police (which there is not).

-Ben

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

Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3

[Sean Turner]

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 TLS 1.3 [1] mandates RSA-PSS in TLS handshake by the 
> following language in sec 4.8.1
> 
>>In RSA signing, the opaque vector contains the signature generated
>>using the RSASSA-PSS signature scheme defined in [RFC3447  
>> ] with MGF1.
>>The digest used in the mask generation function MUST be the same as
>>the digest which is being signed (i.e., what appears in
>>algorithm.signature).  The length of the salt MUST be equal to the
>>length of the digest output.  Note that previous versions of TLS used
>>RSASSA-PKCS1-v1_5, not RSASSA-PSS.
> 
> The
> 
>>   struct {
>>  SignatureAndHashAlgorithm algorithm;
>>  opaque signature<0..2^16-1>;
>>   } DigitallySigned;
> 
> defines RSA PKCS#1 1.5 and RSA PSS as "rsa" and "rsapss", see sec A.3.1.1:
> 
>>   enum {
>>   rsa(1),
>>   dsa(2),
>>   ecdsa(3),
>>   rsapss(4),
>>   eddsa(5),
>>   (255)
>>   } SignatureAlgorithm;
> 
> since draft -09 (posted Oct 2015). "rsa" applies to X.509 certificates only.
> 
> 
> Many implementers of TLS 1.3 expressed desire for the TLS 1.3 to be as 
> frictionless as possible regarding the upgrade of existing TLS installations 
> to TLS 1.3. We should expect that all TLS 1.3 servers and clients will have 
> support for older versions of TLS on the same node. Ideally, it should be 
> possible to upgrade the software / firmware to add TLS 1.3 support on 
> existing hardware with minimal penalty.
> 
> Unfortunately, the product I work on, which is responsible for ~15% of 
> Internet traffic, is not compatible with the "frictionless idea" due to the 
> current TLS 1.3 spec [1] mandating PSS in the handshake.
> 
> The issue here is that these already sold products use 3d party components 
> that can only perform RSA signing with CRT optimization when the padding is 
> PKCS1 1.5. In the best case this means ~2x performance penalty for TLS 1.3. 
> In the worst case the existing server keys cannot do PSS signature if the 
> keys are on FIPS-certified devices.
> 
> The same issue applies to client TLS authentication with smartcards. Many 
> smartcards cannot do PSS, e.g. [3].
> 
> Likewise, it's unclear if PSS is supported by e.g. PKCS#11 libraries of HSM 
> vendors, or the HSM hardware.
> 
> Other products on the Internet use the same components, so that 15% is a 
> minimum I know of.
> 
> The current list of FIPS 140 products that support RSA shows twice as many 
> products that support RSASSA-PKCS1_V1_5 than these that support RSASSA-PSS 
> [4]. There is greater than 50% chance to lose FIPS certification with TLS 
> 1.3, factoring client auth and servers.
> 
> Can support for PSS be added by 3d party vendors? If the limitation is in 
> middleware like PKCS#11 or in firmware/microcode, this is technically 
> possible. This does require an update and the brings version dependency. 
> Further, if the firmware is FIPS 140-2 certified, this type of upgrade will 
> have re-certification cost (more friction). In some cases this is a physical 
> limitation. For example, I know from my experience working on smartcard 
> decryption a few years back that the chips themselves insist on PKCS#1.5 
> padding for half of the vendors we supported and won't e.g. accept raw or 
> OAEP padding with RSA, e.g. [2]. It is apparent from the specs that [3] does 
> support PSS while [2] doesn't.
> 
> I prepared the slides on this subject for Yokohama [5]. I believe Eric 
> Rescorla presented these.
> 
> How much do the members of the WG value the idea of lower hurdles to the 
> deployment of TLS 1.3? Is there desire to add a PKCS#1 1.5 signature 
> fallback, just like there is one already for X.509 certificates in TLS 1.3?
> 
> 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 probably won't be 
> enabled by default in the product I work on. I would prefer for TLS 1.3 to be 
> enabled by default and write the code to decide whether it does PSS or falls 
> back to RSA PKCS1 1.5.
> 
> Thank you.
> 
> [1] http://tools.ietf.org/html/draft-ietf-tls-tls13-11.html
> [2] 4.4 has no PSS: 
> http://jp.atos.net/content/dam/global/we-do/cardos-datenblatt.pdf
> [3] 5.0 has PSS: 
> https://atos.net/content/dam/global/we-do/cardos-v5-datenblatt.pdf
> 
> [4] 2x more legacy than PSS: 
> http://csrc.nist.gov/groups/STM/cavp/documents/dss/rsanewval.html
> wget http://csrc.nist.gov/groups/STM/cavp/documents/dss/rsanewval.html
> $ grep RSASSA-PSS rsanewval.html | wc -l
> 593
> $ grep RSASSA-PKCS1_V1_5 rsanewval.html | wc -l
> 2005
> $ grep RSASSA 

Re: [TLS] Simplifying signature algorithm negotiation

[David Benjamin]

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, I should have looked at that more carefully.

I still think this change is worthwhile. If we expect that future signature
algorithms look like ed25519, this scheme only gives us 256 values to
allocate from and wastes one of the bytes, and it also simplifies and
unifies the interface for signature algorithms. The other benefits from
incorporating curve preferences into the negotiation also still apply.

David

On Fri, Jan 22, 2016 at 5:25 PM David Benjamin 
wrote:

> I've put together a pull request with some initial text for this proposal
> if folks decide to adopt it.
> https://github.com/tlswg/tls13-spec/pull/404
>
> (I'm sure there's no end of editorial problems. I think this is the first
> time I've done non-trival spec work.)
>
> David
>
>
> On Fri, Jan 15, 2016 at 3:45 PM David Benjamin 
> wrote:
>
>> Hi folks,
>>
>> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS
>> 1.2, signature algorithms are spread across the handshake. We have
>> SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and HashAlgorithm, all in
>> independent registries. NamedGroup is sent in one list, also used for
>> (EC)DH, while the other two are sent as a pair of (HashAlgorithm,
>> SignatureAlgorithm) tuples but live in separate registries.
>>
>> This is a lot of moving parts. Signature negotiation in TLS 1.2 tends to
>> be messy to implement. Client certificate keys may be in smartcards via
>> OS-specific APIs, so a lot of time is spent transiting new preference
>> shapes across API boundaries in order to discover smartcard bugs. Sometimes
>> I think people deploy client certs because they hate me and want to cause
>> me pain… :-)
>>
>> Anyway, the new CFRG curves also bind signature curve and hash together.
>> The current draft represents this as eddsa_ed25519 and eddsa_ed448
>> NamedGroups and eddsa SignatureAlgorithm. But this doesn’t capture that
>> EdDSA + Ed25519 + SHA-256 is illegal. (Or ECDSA + FF3072.)
>>
>> I propose we fold the negotiable parameters under one name. Think of how
>> we’ve all settled on AEADs being a good named primitive with a common type
>> signature[1]. Specifically:
>>
>> 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From now
>> on, NamedGroup is only used for (EC)DH.
>>
>> 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm as
>> they are. Introduce a new SignatureAlgorithm u16 type and negotiate that
>> instead. (Or maybe a different name to not collide.) u8 is a little tight
>> to allocate eddsa_ed25519 and eddsa_ed448 separately, but u16 is plenty.
>>
>> 3. Allocate values for SignatureAlgorithm wire-compatibly with TLS 1.2 by
>> (ab)using the old (HashAlgorithm, SignatureAlgorithm) tuples. 0x0401
>> becomes rsa_pkcs1_sha256, etc. Reserve ranges consistently with
>> HashAlgorithm from TLS 1.2. Note this does not introduce new
>> premultiplications on the wire. Just in the spec and registry.
>>
>> 4. Deprecate ecdsa_sha256, etc., in favor of new
>> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_*
>> values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this
>> introduces new premultiplications, it’s only 9 values with the pruned TLS
>> 1.3 lists. I think this is worth 9 values to keep NamedGroups separate.
>>
>> 5. Add new allocations for eddsa_ed25519, eddsa_ed448, and
>> rsapss_{sha256,sha384,sha512}. These come with the signature algorithm and
>> curve pre-specified. (See [2] at the bottom for full list of allocations.)
>>
>> Thoughts?
>>
>> David
>>
>> [1] We’re stuck with RSA-PSS's generality, so that'll need some mapping
>> to a subset of X.509's RSA-PSS. We'll just not bother with RSA-PSS with
>> hashAlgorithm SHA-256, maskGenAlgorithm
>> MGF-7-v3.0-SHA-334-saltLengthQuotient-5/7, saltLength 87, trailerField 14.
>> And RSA key generation still has size parameter. Hopefully future things
>> can look more like Ed25519.
>>
>> [2]
>> 0x-0x06ff - Reserved range for TLS 1.2 compatibility values. Note
>> this is wire-compatible with TLS 1.2.
>> - 0x0101 - rsa_pkcs1_md5
>> - 0x0201 - rsa_pkcs1_sha1
>> - 0x0301 - rsa_pkcs1_sha224
>> - 0x0401 - rsa_pkcs1_sha256
>> - 0x0501 - rsa_pkcs1_sha334
>> - 0x0601 - rsa_pkcs1_sha512
>> - 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3.
>> - 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility but
>> ignored in TLS 1.3.
>>
>> 0x0700-0xfdff - Allocate new values here. Optionally avoid 0x??0[0-3] to
>> avoid colliding with existing signature algorithms, but I don’t think
>> that’s necessary[3].
>> - rsapss_sha256
>> - rsapss_sha384
>> - rsapss_sha512
>> - ecdsa_p256_sha256
>> - ecdsa_p256_sha384
>> - 

Re: [TLS] Require deterministic ECDSA

[Salz, Rich]

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

Re: [TLS] Require deterministic ECDSA

[Jacob Maskiewicz]

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

Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3

[Russ Housley]

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 available at this point is conditioning
>> TLS
>> 1.3 support on appropriate hardware. For this reason TLS 1.3 it
>> probably won't be enabled by default in the product I work on. I
>> would prefer for TLS 1.3 to be enabled by default and write the
>> code
>> to decide whether it does PSS or falls back to RSA PKCS1 1.5.
> 
> Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not
> cutting it off now would be negligent.
 
 You mean for HS only, while leaving it for X.509 certs?
>>> 
>>> If we don't do it for HS in TLS first, we'll never get rid of it in
>>> X.509 certs.
>>> 
>>> We need to start somewhere, and it's more reasonable to expect that
>>> hardware with support for new protocols will get updated for RSA-PSS
>>> handling than that libraries and hardware will suddenly start
>>> implementing it in droves just in anticipation of the time when CAs
>>> _maybe_ will start issuing certificates signed with RSA-PSS.
>> 
>> Isn't it more a matter of TLS being a consumer of external PKIX
>> infrastructure, the web PKI, etc.?  They are out of the reach of the
>> IETF TLS working group; any requirements we attempted to impose would
>> be unenforceable, even if there was an Internet Police (which there
>> is not).
> 
> TLS will happily use PKCS#1 v1.5 signed X.509 certificates, so how 
> exactly is creating a side effect of increasing the deployment rate of 
> RSA-PSS _in TLS implementations_ an "overreach"?!

I have been a supporter of PSS for a very long time -- see RFC 4055.

We have many algorithm transition issues, but this is one place where we have 
seen very little progress.  I would like to see support for PSS in the 
protocol, even if we need to support PKCS v1.5 for certificate signatures for a 
long time.

Russ


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

Re: [TLS] Require deterministic ECDSA

[Hubert Kario]

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 determine whether or not
> > the signer did a deterministic signature.
> > 3) A TLS implementation has no way (absent repeating signatures over
> > identical data) of telling whether or not a given signature using
> > the
> > client or server private key is deterministic.
> > 
> > All that suggests that this is a completely unenforceable
> > requirement
> > with respect to TLS.
> 
> We can have unverifiable & unenforceable MUSTs. A SHOULD might be more
> appropriate, however, if we want to acknowledge this limitation to
> some degree.

a MUST is only necessary if you are not sure or simply know that your 
RNG is broken, if you're doing a HSM implementation you know that your 
RNG is good so you can just use it

and while we can have unverifiable MUSTs, it just looks silly if you do, 
especially if the other way of doing things is just as interoperable, 
and just as secure (if implemented properly) as the mandated one...

SHOULD with explanation why it's there is definitely better approach
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls