[TLS] Sending Custom DHE Parameters in TLS 1.3

[Michael D'Errico]

Hi,

It appears that there may be a need to revert to the
old way of sending Diffie-Hellman parameters that
the server generates.  I see that TLS 1.3 removed
this capability*; is there any way to add it back?

Mike


*From RFC 8446:

- Other cryptographic improvements were made,
  including changing the RSA padding to use the RSA
  Probabilistic Signature Scheme (RSASSA-PSS), and
  the removal of compression, the Digital Signature
  Algorithm (DSA), and custom Ephemeral Diffie-
  Hellman (DHE) groups.

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

[TLS] Weak Diffie-Hellman Primes (was: DH generator 2 problem?)

[Michael D'Errico]

On Fri, Oct 9, 2020, at 11:17, Christopher Wood wrote:
> Michael, since your question is more related to the cryptographic 
> primitives used by TLS than the protocol itself, the chairs encourage 
> you to continue this discussion on the CFRG mailing list [2]. 
> 
> Thanks,
> Chris, on behalf of the chairs
> 
> [1] ...
> [2] https://mailarchive.ietf.org/arch/browse/cfrg/

Hi,

As requested, I sent the message below to the CFRG
mailing list on the 10th.  I did not join the list, but have
been watching via the link [2] above and so far nobody
has said anything.

Mike



To: cfrg at irtf dot org

Hi,

I'm not a member of this list, but was encouraged to
start a discussion here about a discovery I made
w.r.t. the published Diffie-Hellman prime numbers in
RFC's 2409, 3526, and 7919.  These primes all have
a very interesting property where you get 64 or more
bits (the least significant bits of 2^X mod P for some
secret X and prime P) detailing how the modulo
operation was done.  These 64 bits probably reduce
the security of Diffie-Hellman key exchanges though
I have not tried to figure out how.

The number 2^X is going to be a single bit with value
1 followed by a lot of zeros.  All of the primes in the
above mentioned RFC's have 64 bits of 1 in the most
and least significant positions.  The 2's complement
of these primes will have a one in the least significant
bit and at least 63 zeros to the left.

When you think about how a modulo operation is done
manually, you compare a shifted version of P against
the current value of the operand (which is initially 2^X)
and if it's larger than the (shifted) P, you subtract P at
that position and shift P to the right, or if the operand
is smaller than (the shifted) P, you just shift P to the
right without subtracting.

Instead of subtracting, you can add the 2's complement
I mentioned above.  Because of the fact that there are
63 zeros followed by a 1 in the lowest position, you will
see a record of when the modulo operation performed
a subtraction (there's a one) and when it didn't (there's
a zero).

You can use the value of the result you were given by
your peer (which is 2^X mod P) and then add back the
various 2^j * P's detailed wherever the lowest 64 bits
had a value of 1 to find the state of the mod  P operation
when it wasn't yet finished.  This intermediate result is
likely going to make it easier to determine X than just a
brute force search.

I don't plan to join this list, though I am flattered to have
been asked to do so.  I'm not a cryptographer.

Mike

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

Re: [TLS] Sending Custom DHE Parameters in TLS 1.3

[Ilari Liusvaara]

On Mon, Oct 12, 2020 at 12:36:06PM -0400, Michael D'Errico wrote:
> 
> It appears that there may be a need to revert to the
> old way of sending Diffie-Hellman parameters that
> the server generates.  I see that TLS 1.3 removed
> this capability*; is there any way to add it back?

The Diffie-Hellman support in TLS 1.2 is severly broken. There is no
way to use it safely on client side. This has lead to e.g., all the web
browers to remove support for it.

There is no way to ensure that the parameters sent are not totally
broken, e.g.:

- Modulus too small.
- Modulus too large.
- Modulus not prime (has been used as a backdoor!).
- Modulus is weak (possibly backdoored).
- Subgroup order does not have large prime factor.

Even checking the third would require primality test, and primality
tests at relevant sizes are slow. And the fourth and fifth can not be
checked at all in general case.


For ECDHE, TLS 1.2 allowed server to specify custom curve to do the
key exchange with. Rightfully pretty much nobody implemented that.


I think TLS WG should withdraw recommendation (as flawed) on all
TLS_DHE_* ciphersuites.


-Ilari

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

Re: [TLS] Sending Custom DHE Parameters in TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

I suggest that custom parameters should be allowed, and documented as 
completely under user/administrator responsibility.

Ensuring that a custom modulus is not "too small" or "too large" (etc.) in that 
case is not your problem or your business.



On 10/12/20, 13:32, "TLS on behalf of Ilari Liusvaara"  wrote:

On Mon, Oct 12, 2020 at 12:36:06PM -0400, Michael D'Errico wrote:
> 
> It appears that there may be a need to revert to the
> old way of sending Diffie-Hellman parameters that
> the server generates.  I see that TLS 1.3 removed
> this capability*; is there any way to add it back?

The Diffie-Hellman support in TLS 1.2 is severly broken. There is no
way to use it safely on client side. This has lead to e.g., all the web
browers to remove support for it.

There is no way to ensure that the parameters sent are not totally
broken, e.g.:

- Modulus too small.
- Modulus too large.
- Modulus not prime (has been used as a backdoor!).
- Modulus is weak (possibly backdoored).
- Subgroup order does not have large prime factor.

Even checking the third would require primality test, and primality
tests at relevant sizes are slow. And the fourth and fifth can not be
checked at all in general case.


For ECDHE, TLS 1.2 allowed server to specify custom curve to do the
key exchange with. Rightfully pretty much nobody implemented that.


I think TLS WG should withdraw recommendation (as flawed) on all
TLS_DHE_* ciphersuites.


-Ilari

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


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Sending Custom DHE Parameters in TLS 1.3

[Michael D'Errico]

Would it be possible to define a new dual-DH exchange
where you do one with server-supplied parameters, and
a second one with client-supplied parameters, so if one
is broken or sabotaged the connection is still secure?

Mike


On Mon, Oct 12, 2020, at 13:35, Blumenthal, Uri - 0553 - MITLL wrote:
> I suggest that custom parameters should be allowed, and documented as 
> completely under user/administrator responsibility.
> 
> Ensuring that a custom modulus is not "too small" or "too large" (etc.) 
> in that case is not your problem or your business.
> 
> 
> 
> On 10/12/20, 13:32, "TLS on behalf of Ilari Liusvaara" 
>  wrote:
> 
> On Mon, Oct 12, 2020 at 12:36:06PM -0400, Michael D'Errico wrote:
> > 
> > It appears that there may be a need to revert to the
> > old way of sending Diffie-Hellman parameters that
> > the server generates.  I see that TLS 1.3 removed
> > this capability*; is there any way to add it back?
> 
> The Diffie-Hellman support in TLS 1.2 is severly broken. There is no
> way to use it safely on client side. This has lead to e.g., all the web
> browers to remove support for it.
> 
> There is no way to ensure that the parameters sent are not totally
> broken, e.g.:
> 
> - Modulus too small.
> - Modulus too large.
> - Modulus not prime (has been used as a backdoor!).
> - Modulus is weak (possibly backdoored).
> - Subgroup order does not have large prime factor.
> 
> Even checking the third would require primality test, and primality
> tests at relevant sizes are slow. And the fourth and fifth can not be
> checked at all in general case.
> 
> 
> For ECDHE, TLS 1.2 allowed server to specify custom curve to do the
> key exchange with. Rightfully pretty much nobody implemented that.
> 
> 
> I think TLS WG should withdraw recommendation (as flawed) on all
> TLS_DHE_* ciphersuites.
> 
> 
> -Ilari
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> Attachments:
> * smime.p7s

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

Hi Mike,

On Sat, Oct 10, 2020 at 01:29:13PM -0400, Michael D'Errico wrote:
> On Fri, Oct 9, 2020, at 17:22, Benjamin Kaduk wrote:
> > [...]  The behavior we should demand from our cryptographic
> > constructions is that the cryptography itself correctly returns
> > "valid" or "invalid" based on the input message, provided that
> > the application inputs the correct key material.  (It should also
> > return "invalid" if incorrect key material is supplied, of course.)
> > The ability to produce two different messages for which the
> > cryptography returns "valid" violates this principle; even if we
> > do not see an obvious path by which a reasonable application
> > might supply those inputs to the cryptographic code, it is still
> > a flawed construction.
> 
> Hi,
> 
> I'd like clarification about this point, where the cryptography
> should return values of "valid" or "invalid".  This is a general
> question, not specifically about this draft.  (Please read at
> least the next 2 paragraphs.)
> 
> I remember a long time ago, it may have been the renegotiation
> info extension, where there was a lot of calculation being done,
> there were two complicated values each side had to compute.
> If they were equal, then everything was fine and the handshake
> could proceed.  If not, there was an insecure renegotiation
> happening.  (Or maybe it was the downgrade protection RFC,
> I can't remember now.)  But if the values were not equal, then
> something bad was happening and the handshake should not
> proceed.
> 
> The problem both Martin Rex and I discovered at nearly the
> same time (posts to the mailing list within minutes of each
> other) was that both sides could go through all the motions
> faithfully calculating all of the values, correctly, and then
> forget to compare them to see if the values were actually
> the same.  I noticed this because I wrote the code, and it
> seemed like an easy thing to overlook.
> 
> I remember suggesting that we somehow incorporate the
> calculated values into the derivation of the record layer keys
> so the MAC would fail, or maybe into the Finished message
> calculation so (if you remember to check that?) a failure is
> noticed later.  This suggestion was shot down by the author
> unilaterally for what I perceived at the time to be petty
> reasons.
> 
> I still believe that (D)TLS security should not rely on the
> implementer to check whether two values are equal.  This
> is too easy to forget to do.  Or you could do this in C:
> 
> if (complex_value_a = complex_value_b) {
> // we're in trouble
> }
> 
> I have not looked at the TLS 1.3 draft beyond the hour or so
> I've put in so far to see whether this reliance on checking is
> in there too.  I've also not checked whether the security

The TLS 1.3 handshake transcript is an input to the key schedule; manual
comparison of generated values is not necessary for security.

I would encourage you to continue in your efforts reading RFC 8446 -- in my
opinion we put quite a bit of effort in towards making it readable.  (With,
perhaps, the exception of stateless HelloRetryRequest as you have already
noted, since the main expected use case is in DTLS.)

-Ben

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

Hi Achim,

On Sun, Oct 11, 2020 at 07:43:14PM +0200, Achim Kraus wrote:
> Hi Watson,
> 
> > The doubt is because of where it appears not that it appears. If every
> > value was preceded by its length the encoding would obviously be
> > injective.
> 
> I hope, this is just a "typo" or "mistake".
> 
> Prepending the length is the change, Ben want to use to protect against
> injection. You now say, this will be "obviously injective".

Since apparently this was not fully clear, allow me to link the wikipedia
article corresponding to "injective map (in the mathematical sense)" in my
earlier description: https://en.wikipedia.org/wiki/Injective_function

> > Here though it isn't clear if two different inputs to the
> > encoding could end up the same.
> 
> Though the MAC definition starts with "MAC_write_key", I'm pretty sure,
> all examples so far are just incomplete. They must declare, if the
> "different/ambiguous" CIDs are refer to the same "MAC_write_key" or not.
> 
> "different MAC_write_key" => obviously "end up" different.
> "same MAC_write_key" => the decoding of the records gets ambiguous
> 
> > In fact I think in the MAC setting
> > there almost certainly is a problem as the length of the ciphertext is
> > right after the cid length, and with some cleverness you can come up
> > with a cid and ciphertext that could be interpreted multiple ways.
> > Unfortunately I haven't followed the draft's discussions that closely.
> >
> > I do not understand how a CID is supposed to be parsed by a recipient
> > when the length can change and the length field is not encoded, but
> > perhaps I'm misreading the intent of the [] notation in the record
> > layer of the draft.
> 
> That's just a theroretical numbers game. No one os far made any really
> useful example from start to end. FMPOV, "CID with dynamic length" MUST

In my opinion a useful example from start to end is not a prerequisite for
making a change to the spec in the face of a demonstrated local weakness.
Attacks only ever get better, and we should not leave known building blocks
for them in place.

> use a unique/deterministic encoding. If that encoding ambiguous, as
> others imply/assume in their "numbers game", the whole record gets
> ambiguous.

Yes, an entity assigning its own CIDs has to be able to distinguish them on
receipt based on the record bitstream (which does not supply its own
framing for the CID length).  The current text may not be as explicit about
this requirement as it could be (it may only list a requirement that the
values given out have to be recognized, not that there has to be a unique
parsing of all potential CID bytestreams in a received record that rejects
invalid ones?  I didn't check).

> Just as forecast:
> Without agreement, that the CIDs must be encoded using deterministic
> interpretation, which in my opinion obsoletes these "number games",
> next Summer either Raccoon or Kenny will write up their next
> "time side channel attack" on this.
> (The ambiguity will end up in try out the MAC for both "different
> MAC_write_key" and so create a time signal. Or with "same MAC_write_key"
> the receiver will not know by the failing MAC, which interpretation is
> the right. I guess, this will end up in decrypt twice, also obvious time
> signal.)

Just to check my understanding: your forecast of an attack is predicated on
implementations that accept both potential MAC calculations proposed (CID
length before CID and CID length after CID)?  I do not think we should
allow things to progress to a state where accepting both forms is
encouraged, precisely because it leads to this sort of difficulty.   Hence,
my suggestion to assign a different extension codepoint, so an
implementation knows exactly which procedure to use.

-Ben

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

Re: [TLS] Sending Custom DHE Parameters in TLS 1.3

[Salz, Rich]

>It appears that there may be a need to revert to the
old way of sending Diffie-Hellman parameters that
the server generates.

Can you explain why?  Something stronger than "I think that ..." is probably 
needed to convince the WG.
 

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

On Sat, Oct 10, 2020 at 09:13:51AM +0200, Achim Kraus wrote:
> Hi Ben,
> 
> >
> > To be frank, I'm actually surprised that this is even seen as a matter for
> > discussion.
> 
> As developer, I'm surprised, that this discussion now spans a couple of
> years, starting on summer 2018 with:
> 
> https://github.com/tlswg/dtls-conn-id/issues/8

Well, we are not always happy about it (in fact, usually are unhappy), but
writing protocol specifications does have a reputation for taking a long
time due to repeated experiences.  It's also the case that the spec isn't
done until it's done, and that breaking changes to the spec are possible at
any time before it's done.

> There are many (proposed) changes since then. I already tried to point
> to that with my e-mail answer from 4. September
> 
>  >> That order was also discussed a lot.
>  >> https://github.com/tlswg/dtls-conn-id/pull/29
>  >> I would prefer, if this is not changed again without strong arguments!
> 
> For me, "cryptographic hygiene", which breaks the API, are not strong
> arguments. Sure, that's only my personal opinion. I'm not sure, if a new
> code-point helps, nor that a new one is emitted for changing a draft (I
> would not recommend to do so, draft is a draft).

A codepoint should have a specific well-defined behavior.  The current
allocation of extension type 53 is explicitly marked as TEMPORARY and
can+will age out if we get a new one for the new semantics; this is normal.

> So let me try to find a end:
> As developer, I see it's very important to come to a stable definition
> of the MAC. If now the order of the cid/cid-length is changing the MAC
> (again), and in half a year the next "cryptographic hygiene" campaign
> removes the cid-length (because it's not on the header and some
> (including me) don't see the benefit), then FMPOV this "process" just
> demonstrates more weakness, than I appreciate.
> 
> So:
> If there is a guideline for constructing MACs, is that guideline
> documented somewhere?
> If the guideline is changing over the time, are these changes documented?

Sure, there's pretty standard common-knowledge guidance, though I'm not
sure it's documented anyplace particularly discoverable:

- include in the MAC as much application/protocol context and protocol
  fields as you can without breaking operation of the procotol
- ensure that the mapping from (set of protocol fields and values derived
  from application context) to (bytes given as input to the MAC function) is
  an injective mapping

In some (many?) cases, there is not any additional contextual information
available, and the protocol header itself has a deterministic/fixed-length
encoding, so both points can be achieved by just using the protocol
header/payload as it appears on the wire as MAC input.  For better or for
worse, the current construction in the -07 diverges significantly from the
actual protocol header, so we have to do a bit of thinking to ensure that
we are compliant to the guidelines (that I just described, so I assume you
did not previously think about them in that formulation).


For what it's worth, I am in a similar position as you in that I don't see
a specific reason that including the CID length explicitly is *required*,
since the CID itself would need to be using a self-delineating encoding in
order for the packet to be parseable (if variable-length CIDs are used at
all; a fixed-length CID is trivially delineated).  I would be pretty okay
with not having the separate length field if our MAC inputs more closely
followed the record header (and, to be honest, I could accept not having it
at all even with the current order of (other) fields in the MAC input, in
the absence of specific reasoning why it's needed), though I prefer to keep
an explicit length if we stay with something resembling the current
formulation (that diverging from the record header as it appears on the
wire), just to make it easier to reason about.  I still, however, object to
the construction in the -07 that puts the CID length after the CID -- there
is no point in having the CID length if you need a self-delineating CID
anyway [1], and its current location gives an aveue of malleability to an
attacker.  Leaving this kind of local malleability of MAC input in place
seems irresponsible and is not in keeping with the quality expectations for
the output of the TLS working group.

(We should also check to make sure that we properly document the
requirements on CID generation and parsing schemes, as you noted
elsewhere.)

> And I would really welcome, also based on the experience with the long
> history of this discussion, if more can give their feedback about
> changing the MAC again. Please, this year, not next :-).

I believe that Joe's response supports my "don't leave areas of local
malleability in place" stance.  I guess maybe the discussion is migrating
to the github issue, though, so I will try to watch there as well.

Thanks,

Ben

[1] "need [...] anyway" here is perhaps most u

[TLS] draft-vvv-tls-alps-01

[David Benjamin]

Hi all,

Victor and I recently published draft-vvv-tls-alps-01. It has a couple of
changes that I wanted to get the WG’s thoughts on. The changes are
switching the bespoke ClientApplicationSettings message to a client
EncryptedExtensions message and clarifying the 0-RTT handling.

https://tools.ietf.org/html/draft-vvv-tls-alps-01

I think it was EKR who suggested a client EncryptedExtensions message, so
future extensions can more easily add to the client Finished leg. A new
message means picking when it is sent, and a new extensions block means
picking when extensions are allowed. We’ve initially gone with:


   -

   We add a CEE tag to the TLS 1.3 column in the IANA registry.
   -

   The client sends EncryptedExtensions, possibly empty, if and only if the
   server sent at least one CEE-tagged extension in server
   EncryptedExtensions. (No unsolicited server extensions, so the client will
   know the status of each extension.)
   -

   The client may send an extension in EncryptedExtensions if the server
   sent the corresponding extension in server EncryptedExtensions. (Whether it
   is mandatory or optional once negotiated is the extension’s business.)


Other formulations may also work. We picked this to avoid an optional
message (see half-RTT tickets below), and to try to match the existing
scheme.

For 0-RTT, ALPS aims to align with ALPN where we carry over the ticket
state (like ALPN, ALPS is resolved before any application data) and decline
0-RTT on mismatch. That leaves the question of resending the information
(receiver checks it matches) vs omitting it (receiver implicitly carries it
over). ALPN does the former, but we’ve currently gone with the latter for
ALPS. Both seem comparable implementation-wise, but we picked this for
fewer bytes on the wire, and to avoid breaking half-RTT tickets. We’d
particularly like to hear the WG’s thoughts on this last point.

Section 4.6.1 of RFC8446 has the following text:

https://tools.ietf.org/html/rfc8446#section-4.6.1

   Note: Although the resumption master secret depends on the client's

   second flight, a server which does not request client authentication

   MAY compute the remainder of the transcript independently and then

   send a NewSessionTicket immediately upon sending its Finished rather

   than waiting for the client Finished.  This might be appropriate in

   cases where the client is expected to open multiple TLS connections

   in parallel and would benefit from the reduced overhead of a

   resumption handshake, for example.

This relies on the server being able to predict the client Finished flight
in 0-RTT handshakes. Two risks here:


   -

   Whether EncryptedExtensions is sent must be deterministic (as in our
   formulation).
   -

   Extension order is not fixed. If we ever have two client encrypted
   extensions sent over 0-RTT, the server cannot predict which will go first.


We thus punted this in -01 by not sending the redundant extension in 0-RTT
at all. Another option would be locking the client EE extension order. But
I think we should decide whether half-RTT tickets are a constraint we want
to carry going forward.

Half-RTT tickets were originally added for a stateless reject flow in QUIC
that no longer applies. We’ve since found it useful for 0-RTT, to avoid
some problematic I/O patterns. (See
https://mailarchive.ietf.org/arch/msg/tls/hymweZ66b2C8nnYyXF8cwj7qopc, and this
comment
 from
I think an NGINX developer.) We’ve since realized we can avoid the
surprising I/O patterns by deferring NewSessionTicket to the next
application write and have done so in BoringSSL for 1-RTT. For 0-RTT, we
currently still use half-RTT tickets because the cost is connections don’t
deliver tickets until the second application round-trip rather than the
first:

ClientHello
GET /request1 HTTP/1.1
ServerHello..Finished
  HTTP/1.1 200 OK
EndOfEarlyData..Finished
GET /request2 HTTP/1.1
 NewSessionTicket
  HTTP/1.1 200 OK

Delaying this seems surprising and not ideal. We already see that
post-handshake NST is itself surprising to application developers, since
the client only picks up tickets on the first read. This would *further*
delay it to some late read. It’s also something the RFC explicitly says you
can do, and dropping this would contradict that decision. At the same time,
the prediction bits are goofy and constraining.

Thoughts?

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

Re: [TLS] Sending Custom DHE Parameters in TLS 1.3

[Peter Gutmann]

Ilari Liusvaara  writes:

>The Diffie-Hellman support in TLS 1.2 is severly broken. There is no way to
>use it safely on client side. This has lead to e.g., all the web browers to
>remove support for it.

It's actually pretty simple, don't use toy key sizes.  Many implementations
were never vulnerable to Logjam et al because they applied the simple measure
of... not using toy key sizes.

>There is no way to ensure that the parameters sent are not totally broken,
>e.g.:

This requires that the server that you're connecting to is malicious.  If
you're connecting to a malicious server then you've got bigger things to worry
about then what they set g to.

>This has lead to e.g., all the web browers to remove support for it.

Because throwing out the baby with the bathwater and jumping on the next shiny
thing that comes along every time someone points out a problem seems to be a
requirement for crypto protocol implementers.

Peter.


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

Re: [TLS] Sending Custom DHE Parameters in TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

In some cases toy key sizes are necessary. 

E.g., classes where your students break encryption because the keys are weak or 
small.

Regards,
Uri

> On Oct 12, 2020, at 19:42, Peter Gutmann  wrote:
> 
> Ilari Liusvaara  writes:
> 
>> The Diffie-Hellman support in TLS 1.2 is severly broken. There is no way to
>> use it safely on client side. This has lead to e.g., all the web browers to
>> remove support for it.
> 
> It's actually pretty simple, don't use toy key sizes.  Many implementations
> were never vulnerable to Logjam et al because they applied the simple measure
> of... not using toy key sizes.
> 
>> There is no way to ensure that the parameters sent are not totally broken,
>> e.g.:
> 
> This requires that the server that you're connecting to is malicious.  If
> you're connecting to a malicious server then you've got bigger things to worry
> about then what they set g to.
> 
>> This has lead to e.g., all the web browers to remove support for it.
> 
> Because throwing out the baby with the bathwater and jumping on the next shiny
> thing that comes along every time someone points out a problem seems to be a
> requirement for crypto protocol implementers.
> 
> Peter.
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Ben,




Just as forecast:
Without agreement, that the CIDs must be encoded using deterministic
interpretation, which in my opinion obsoletes these "number games",
next Summer either Raccoon or Kenny will write up their next
"time side channel attack" on this.
(The ambiguity will end up in try out the MAC for both "different
MAC_write_key" and so create a time signal. Or with "same MAC_write_key"
the receiver will not know by the failing MAC, which interpretation is
the right. I guess, this will end up in decrypt twice, also obvious time
signal.)


Just to check my understanding: your forecast of an attack is predicated on
implementations that accept both potential MAC calculations proposed (CID
length before CID and CID length after CID)?  I do not think we should
allow things to progress to a state where accepting both forms is
encouraged, precisely because it leads to this sort of difficulty.   Hence,
my suggestion to assign a different extension codepoint, so an
implementation knows exactly which procedure to use.



My concerns are based on permit ambiguous CIDs.

> Attempting to construct a trivial example on the fly, (hex)

> 01 01 02 02 01 <513 bytes of plaintext content>

> could be cid_length=1, cid=0x01, length_of_DTLSInnerPlaintext=0x0202,
> DTLSInnerPlaintext.content = 0x01 <513 bytes>, or it could be
> cid_length=2, cis=0x0101, length_of_DTLSInnerPlaintext=0x0201,
> DTLSInnerPlaintext.content = <513 bytes>.

That results in my opinion in cid 01 and cid 01 01 being valid for the
same peer and same time.

or

> - Application record on CID 63 containing 04 00 02 FF, or
> - Application record on CID 63 01 00 05 containing FF.

being valid for the same peer and same time.

That seems to be the precondition for the threats. Permitting such
ambiguous CIDs may be then the root cause for such a "time side channel".

With the reference from Antoine (https://eprint.iacr.org/2020/114.pdf,
Section III.D), I started to consider the encoding of a "variable length
CID" to be the real spot. That points for me to the same direction, it's
that encoding not the position of the cid-lenght.

best regards
Achim Kraus

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Ben,


Sure, there's pretty standard common-knowledge guidance, though I'm not
sure it's documented anyplace particularly discoverable:

- include in the MAC as much application/protocol context and protocol
   fields as you can without breaking operation of the procotol
- ensure that the mapping from (set of protocol fields and values derived
   from application context) to (bytes given as input to the MAC function) is
   an injective mapping

In some (many?) cases, there is not any additional contextual information
available, and the protocol header itself has a deterministic/fixed-length
encoding, so both points can be achieved by just using the protocol
header/payload as it appears on the wire as MAC input.  For better or for
worse, the current construction in the -07 diverges significantly from the
actual protocol header, so we have to do a bit of thinking to ensure that
we are compliant to the guidelines (that I just described, so I assume you
did not previously think about them in that formulation).



Hope, I'm not again catched by my bad english :-):

If the forumlation refers to draft-ietf-tls-dtls-connection-id-07 (and
not my e-mails), I can't say, what was thought or not by the authors. My
role in that discussion quite a year ago, was just to ask, which of the
many variants should then be chosen in order not to change it every year.

That's also the main thing, which drives me to this endless discussion.
If it changes again, try to change it that last time.

best regards
Achim Kraus

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

Re: [TLS] Sending Custom DHE Parameters in TLS 1.3

[Henrick Hellström]

On 2020-10-12 19:28, Ilari Liusvaara wrote:

On Mon, Oct 12, 2020 at 12:36:06PM -0400, Michael D'Errico wrote:


It appears that there may be a need to revert to the
old way of sending Diffie-Hellman parameters that
the server generates.  I see that TLS 1.3 removed
this capability*; is there any way to add it back?


The Diffie-Hellman support in TLS 1.2 is severly broken. There is no
way to use it safely on client side. This has lead to e.g., all the web
browers to remove support for it.


You have to excuse me, but there is a fair amount of noise in this 
group, and it is sometimes hard to find the information you are looking 
for, in past discussions held years or even decades ago.


But surely DHE support can't be considered broken at the protocol level, 
because the client can't confirm that the server implementation of DHE 
parameter generation isn't broken? There are gazillion of ways the 
server implementation might be broken, that the client has absolutely no 
way to test, regardless of which TLS protocol it supports. I do not 
think I have to go into details.


If I remember correctly, the problem was rather that some of the most 
common implementations had made a habit out of using poorly chosen 
parameters, and the automated security testing tools couldn't easily 
tell flawed servers, from servers that had fixed this issue. It wasn't 
really a protocol issue, but purely an implementation issue.


Correct me if I remember incorrectly.



There is no way to ensure that the parameters sent are not totally
broken, e.g.:

- Modulus too small.
- Modulus too large.
- Modulus not prime (has been used as a backdoor!).
- Modulus is weak (possibly backdoored).
- Subgroup order does not have large prime factor.

Even checking the third would require primality test, and primality
tests at relevant sizes are slow. And the fourth and fifth can not be
checked at all in general case.


For ECDHE, TLS 1.2 allowed server to specify custom curve to do the
key exchange with. Rightfully pretty much nobody implemented that.


I think TLS WG should withdraw recommendation (as flawed) on all
TLS_DHE_* ciphersuites.


-Ilari

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






smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Sending Custom DHE Parameters in TLS 1.3

[Hanno Böck]

Hi,

There was a reason custom DH parameters were removed.
Custom DH parameters were the source of plenty of problems.

I suggest reading:
https://blog.hboeck.de/archives/841-Diffie-Hellman-and-TLS-with-nonsense-parameters.html
https://eprint.iacr.org/2016/644
https://www.openssl.org/news/secadv/20160128.txt

There's also a more general theme I think what we have learned over
time:
Moving parts in crypto protocols are bad, simplicity is good. Fix as
much as you can, avoid negotiating stuff.

This is not talked about that much explicitly, but it is a major change
of how crypto protocols were designed in the past (i.e. TLS 1.2 times)
where it was often considered desirable to add as much flexibility as
possible.

(Also FWIW the relevance of DH is pretty small these days. I think the
largest web clients simply don't support it at all.)

-- 
Hanno Böck
https://hboeck.de/

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