Re: DH group exchange (Re: SSH key algorithm updates)

Niels Möller <[email protected]> writes:

> "Mark D. Baushke" <[email protected]> writes:
>
> > Given your point about sha2-384, I think there are three possibilities
> > that remain:
> >
> >   sha2-512
> >   sha3-256
> >   sha3-512
>
> sha3-384 could also be on that list. Unlike for sha*2*-384, it's a
> different security/performance tradeoff than sha3-512.
>
> > fwiw: I have no idea if the SSH community is ready to consider the use
> > of sha3 (FIPS PUB 202 style) at this time,
>
> Me neither.

Okay. Well, what do other folks on the list think? Is it time to add
SHA3 to the SSH standard for DH Group15 and DH Group16? If so, what
values make the most sense?

fwiw: I do not believe that the SHA-3 family (sha3-224, SHA3-256,
SHA3-512, SHAKE128 and SHAKE256) from FIPS PUB 202 have been added as an
RFC yet.

So, what would be the correct way to handle specification of ay of those
algorithms in an Internet Draft?

I can certainly write an update to RFC 4253 that moves
'diffie-hellman-group1-sha1' to 'NOT RECOMMENDED' and adds
'diffie-hellman-group14-sha256' as 'RECOMMENDED', but I am less sure
about what to add for a diffie-hellman-groupNN-<sha3-HHH> where groupNN
are names from RFC 3526 and sha3-HHH are recommended sizes of the SHA-3
family.

I suppose I could just add a <xref target="FIPS-PUB-202"/> or something,
with

      <reference
        anchor="FIPS-PUB-202"
        target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf">
        <front>
          <title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output
	  Functions</title>
          <author>
            <organization>National Institute of Standards and Technology
	     </organization>
	     <address>
	     <city>Gaithersburg</city>
	     <region>MD</region>
	     <code>20899-8900</code>
	     <country>US</country>
	     </address>
          </author>
          <date month="April" year="2015"/>
        </front>
        <seriesInfo name="FIPS PUB" value="202"/>
      </reference>

but it seems like having an RFC defining the SHA-3 family and its
security considerations first might be reasonable?

	Thanks,
        -- Mark