Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

[Michael StJohns]

On 7/19/2021 10:16 AM, Salz, Rich wrote:

I support publication.


https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/
  


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




Nit - which also applies to draft-ietf-tls-flags:  In the IANA 
considerations section, the Value field is expressed as 0x8 - a hex 
value - rather than 8 a decimal value.  Given that the registry uses 
decimal bit number positions, and that a hex value might be confused 
with a mask (e.g. 0x8 might be confused with bit 5), I'd suggest 
dropping the "0x".   Or, to keep this more in keeping with normal 
practice, specify Value as "TBD" and have the IANA do the actual 
assignment consistent with policy - it's a good way to ensure the WG and 
the IANA are on the same page.  If that change is made, add a "to be 
removed before publication" note to the IANA indicating that you want 
the assignment to be made out of the 8-31 range.  Section 3 would also 
need to change to remove "(8)";


Nit: Section 4 - it's not clear that "Section 4.6.1" refers to RFC8846 
(at least in the text version) as opposed to a mis-numbered section - 
instead I suggest: "Section 4.6.1 of that document"


Mike

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

Re: [TLS] WGLC for draft-ietf-tls-flags

[Michael StJohns]

On 7/16/2021 7:55 PM, Christopher Wood wrote:

This is the second working group last call for the "A Flags Extension for TLS 
1.3" draft, available here:

 https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/

Please review this document and send your comments to the list by July 30, 
2021. The GitHub repository for this draft is available here:

 https://github.com/tlswg/tls-flags

Thanks,
Chris, on behalf of the chairs

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



Hi - I have not followed the discussion of this document on the mailing 
list so this review is only against the document itself. It's possible 
that these concerns have already been discussed.



Section 2 requires  (MUST) the generation of fatal illegal_parameter 
alert upon reception of a mal-encoded extension (e.g. any trailing zero 
bytes), but compare and contrast this with section 3 which is full of 
MUST and MUST NOT declarations but with no concrete actions to be 
taken.  E.g. if I (server or client) send 0x01 0x10, and receive 0x01 
0x11 from the client or server, wouldn't that be an illegal value as 
I've added a bit not sent to me?   Should that cause the same fatal 
illegal_parameter alert? Alternately, "receiver MUST ignore received 
bits that weren't sent" language could clean this up.


Section 4 is a bit painful to read in that it took me three 
read-throughs to understand that what the document is asking for is a 
monolithic registry which requires "expert review" for all 
registrations, but where the experts are responsible for the sub range 
determinations.   Usually, that's not the way the IANA works.  If a 
registry has distinct set of ranges, each range normally has a specific 
registration procedure that the IANA follows before placing a parameter 
in that registry.


I'd strongly suggest reviewing RFC 8126 and chatting with the IANA to 
see if its possible to reform the registration process along more normal 
IANA lines.   E.g.:


0-7 - Standards Action and Expert Request
8-31 - Standards Action
32 - 63 Specification Required or IETF Review (pick one)
64-79 Private Use
80-127 RFU or Expert Review
128-2039 First Come First Served



Absent these two points, the rest of the content looks good.  I'd 
recommend a draft pass to fix these two items.



Later, Mike




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

Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

[Michael StJohns]

On 5/20/2019 3:41 PM, Blumenthal, Uri - 0553 - MITLL wrote:


I reviewed this draft (“browsed through” would be a more honest 
statement). I didn’t spot an obvious problem with it.


One question that I have after reading it: I understand why one wants 
to implement this extension, but I don’t see how the two endpoints 
would arrive at that external PSK.


Sadly - we're back to the 1980's in terms of key management. The obvious 
answers are a) they meet to exchange keys, b) they're given a key 
through a KDC, c) they get them in the mail. (and I'm really not kidding 
about (c))


Mike


*From: *TLS  on behalf of Russ Housley 


*Date: *Monday, May 20, 2019 at 3:21 PM
*To: *Joe Salowey 
*Cc: *IETF TLS 
*Subject: *Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

TLS 1.3 Extension for Certificate-based Authentication with an 
External PSK ensures the US Government has a quantum-resistant option 
for TLS in the interim years until post-quantum algorithms emerge from 
the NIST process. For this reason, there is an intent to specify this 
extension in future procurements.


Russ



On May 15, 2019, at 9:20 AM, Joseph Salowey mailto:j...@salowey.net>> wrote:

The last call has come and gone without any comment.  Please
indicate if you have reviewed the draft even if you do not have
issues to raise so the chairs can see who has reviewed it.  Also
indicate if you have any plans to implement the draft.

On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey mailto:j...@salowey.net>> wrote:

This is the working group last call for the "TLS 1.3 Extension
for Certificate-based Authentication with an External
Pre-Shared Key” draft available at

https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/.
Please review the document and send your comments to the list
by 2359 UTC on 23 April 2019.

Thanks,
Chris, Joe, and Sean




___
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] chairs - please shutdown wiretapping discussion...

[Michael StJohns]

On 7/10/2017 3:38 PM, Stephen Farrell wrote:


On 10/07/17 17:42, Colm MacCárthaigh wrote:

It's clear that there is a strong distaste here for the kind of MITM being
talked about

It is not (only) "distaste," it is IETF policy as a result of
a significant debate on wiretapping.


It is a policy some 17 years ago promulgated with respect to some very 
specific layer 9 threats and was pretty black and white.   In 17 years 
we've gone from workstation class systems homed to application class 
servers to smart phones and the cloud.  The SNI RFC was still three 
years out and strangely all the privacy stuff we're worried about now 
wasn't even part of the security considerations.  TOR was still a DOD 
project.  Basically, 2804 is woefully out of date with respect to the 
current state of the world.


What this discussion has shown me is that we probably a) need to take 
another look at 2804 with a view to updating it with respect to the 
IETF's general views on persistent threats of all kinds, b) need to have 
whatever revision we make of 2804 provide for the concept that the owner 
of the data is not necessarily the sender/receiver of the data and has a 
vested interest in being able to control the flow of that information or 
protect themselves against persistent system threats (e.g. masked 
attackers) implicit in protecting against persistent privacy threats, 
and c) follow the general IETF model of not reading each and every word 
in any given RFC as if it were immutable truth handed down for all 
eternity and trust that we can - if we have the discussion - find a way 
forward through consensus building not bullying.


Later, Mike




S



___
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

[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] Require deterministic ECDSA

[Michael StJohns]

On 1/24/2016 5:12 AM, Yoav Nir wrote:

The HSM has enough entropy to generate (once) a 256-bit (or 384-bit or 521-bit) 
key. When working as part of a TLS server using regular ECDSA it would need to 
generate a random k for each full handshake, and many such servers routinely 
handle tens of thousands of such handshakes per second. So it’s hundreds of 
kilobytes per second, for an HSM that has no network input, no I/O of any kind 
other than the signature requests, this may be a problem. I’ve seen people 
claim this in the past.


This *really* isn't how most HSMs work.  They mostly have TRNGs (True 
Random Number Generators) aka Hardware RNGs based on noisy diodes or 
ring oscillators or some such (e.g. no stupid linux like entropy source 
from keyboard motion or network interrupts).  This gets fed into a PRBG 
construct - something like the ones in SP800-90A.  Which does the 
entropy expansion/extraction to get you pretty much any number of bits 
you want of good quality randomness in plenty of time to do handshakes.


There's actually a cool set of USB devices that provide *very* good 
TRNG.Take a look at 
http://ubld.it/products/truerng-hardware-random-number-generator/ or 
http://ubld.it/ and the drivers (or internal logic) feed what they get 
from the TRNG into a good PRBG.  I've been playing with using them as an 
augmentation of how I generate keys.


If you're stuck on commodity hardware (e.g. intel motherboard)  and 
worried about randomness, there's also this: 
https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide. 
Later versions of the intel platform have a TRNG embedded in them as 
well as an SP800-90A PRBG.


One of the things about FIPS and RNGs is that there is a pretty good set 
of requirements AND tests that can be used to establish just how good of 
an RNG source you have (and provide pretty good error detection and fail 
logics).


Later, Mike



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

[TLS] Fwd: Re: Require deterministic ECDSA

[Michael StJohns]

Sorry - I hit the wrong "reply to" button.


 Forwarded Message 
Subject:Re: Require deterministic ECDSA
Date:   Sat, 23 Jan 2016 20:52:53 -0500
From:   Michael StJohns <m...@nthpermutation.com>
To: Geoffrey Keating <geo...@geoffk.org>



On 1/23/2016 8:05 PM, Geoffrey Keating wrote:

Michael StJohns <m...@nthpermutation.com> writes:


On 1/23/2016 2:13 PM, 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


Correct me if I'm wrong but:

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.

A test suite can easily determine, if it knows the private key in use
by the implementation under test, whether that implementation is
generating RFC 6979 deterministic signatures or not.  That seems to me
an adequate enforcement mechanism.


Um.. not really.   The actual worked example is FIPS.   There are lots
of FIPS TLS implementations and they all go through testing (your
proposed enforcement mechanism), and there is exactly NO way for one
FIPS implementation to ensure that it is talking to another FIPS
implementation.  The best they can do is limit the offer and acceptance
of specific crypto suites.

MUST or "Required"  in IETF parlance is usually reserved for choices
that have to be made to have interoperable products.  Neither FIPS nor
deterministic ECDSA rise to that level.FIPS at least recognizes that
and imposes its requirements on the buyers (US Gov't and US Gov't
contractors) who then ask for FIPS capable products. And people who want
to sell to the government then make FIPS capable products that ... wait
for it... interoperate with non-FIPS products.

From 2119:

  In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions)  For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.


Or would you argue that I'm misinterpreting the above and the impact of
your suggested change?

(Um.. in the above "causing harm" has usually been interpreted to mean
"harm to the network" - not preventing stupidity in implementation).

Later, Mike






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

Re: [TLS] Require deterministic ECDSA

[Michael StJohns]

On 1/23/2016 7:17 PM, Yoav Nir wrote:

Also if the signatures are done in a separate hardware module, that module is 
even less likely to have a good random source.

And if we make it rely on external input for the random, that’s a good way of 
getting it to reveal information about the private key, whereas keeping the 
private key secret forever was the whole point of using a hardware module.

So that’s another argument in favor of deterministic signatures.

Yoav


I tried to parse the above into meaningful A implies B logic and failed.

If you have an HSM, the key that's generating the signature tends to be 
generated inside the HSM.  If your HSM has a bad RNG, then the key 
generation is going to be a problem well before the signature generation 
RNG problem kicks in.   And to clarify, a key generated inside an HSM 
tends to use that HSM's signature mechanism, not something in a separate 
module.


I don't think your argument holds.

"If we make it rely on external input for the random"???   Isn't that 
exactly what the RFC uses in the form of the hashed message?


Mike







On 23 Jan 2016, at 9:59 PM, Joseph Birr-Pixton  wrote:

Hi,

The other benefit is being able to test that a critical code path
produces the correct answers. With randomised k, this is not really
possible. For instance, you can choose k with the top bit clear
without any obvious or externally-testable effects, except effectively
publishing your long-term private key after a large number of
signatures[1].

Given the history of these things, I would perhaps challenge the
assumption that all TLS stacks will have a bug-free, thread-safe,
fork-safe, high quality, uncompromised, backdoor-free, unbiased random
number generator :)

Cheers,
Joe

[1]: 
http://people.rennes.inria.fr/Jean-Christophe.Zapalowicz/papers/asiacrypt2014.pdf

On 23 January 2016 at 19:27, Jacob Maskiewicz  wrote:

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

___
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

[Michael StJohns]

On 1/23/2016 2:13 PM, 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



Correct me if I'm wrong but:

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.


The above is a long way of saying that this is a WG overreach on 
internal security module behavior that is not central, cognizable or 
identifiable to a TLS implementation.


I'd instead recommend you approach the CFRG and offer a internet draft 
with a target of BCP on the general topic of ECDSA rather than specific 
guidance for TLS.


Mike





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

Re: [TLS] Require deterministic ECDSA

[Michael StJohns]

On 1/23/2016 3:16 PM, Geoffrey Keating wrote:

But if k generation is broken, then that
leaks the key permanently and you need to get a new one and revoke the
old one, which may be difficult.


I agree that if RNG generation is broken then it breaks k generation.
But if RNG generation was broken during key generation, you also have a 
problem.


In your arguments, assuming that the RNG was fine for key generation and 
broken for signature generation IMHO only applies to software modules 
(where you have the option of using separate RNGs for different functions).


For HSMs with any reasonable amount of good design, if the RNG is bad, 
the thing just stops working (and there are ALL sorts of tests to ensure 
that).


With respect to a software module, I'd find it easier just to read the 
key bits out of memory than apply most of the other threats that seem to 
be creeping into the argument.


Later, Mike



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

Re: [TLS] A small detail in HMAC key generation for Finished message

[Michael StJohns]

On 12/23/2015 8:04 PM, Christian Huitema wrote:

On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote:

I wonder what the zero length string actually means. Is it a null-terminated 
string
that would encode in binary as a one octet byte string of value 0, or an empty
string that would encode in binary as a zero length string?

I see what you mean about the ambiguity here. What I meant was 0 bytes
(i.e., no trailing '\0').

OK, makes sense.


There is one example of encoding a string in section 4.8.1, and the binary 
representation
shows the encoding of the final null byte. Is that a common assumption?

No.


Similarly, in the HKDF-Expand-Label, do we assume a final null byte for the 
"label"?

No. I wonder if we should instead add the '\0' explicitly in the 4.8.1 for 
maximal clarity.

Either that, or just remove the trailing 00 from the binary description.


Or even better.  Express the label as a specific sequence of octets as 
the normative form for each and every label.   That then avoids 
questions of the form "C String"?  "Ascii"?, "Wide characters"?, etc.


Mike



-- Christian Huitema

___
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