Subject: Nits in current drafts

From: Ben Harris <[email-masked]>
Date: Sun, 20 Feb 2005 12:46:49 +0000 (GMT)

I've mentioned some of these before, but all of them still apply to the 
set of drafts released on Friday.

draft-ietf-secsh-transport-23.txt:

Section 6.4: replace "The hash algorithms are described in [SCHNEIER]." 
with "The SHA-1 hash algorithm is described in [FIPS-180-2].  The MD5 hash 
algorithm is described in [RFC1321]."

Section 6.6: replace each occurrence of "the SHA-1 hash" with "the SHA-1 
hash, as defined in [FIPS-180-2],".

Section 6.6: replace "according to [SCHNEIER] and [RFC3447]" with 
"according to the RSASSA-PKCS1-v1_5 scheme of [RFC3447]".

Sections 8.1, 8.2: replace each occurrence of "SHA-1" with "SHA-1, as 
defined in [FIPS-180-2],".

Section 15.1: delete references [RFC2693] and [RFC3280].

Section 15.1: add references:

    <reference anchor="RFC1321">
     <front>
      <title>The MD5 Message-Digest Algorithm</title>
      <author initials='R.' surname='Rivest' fullname='Ronald L. Rivest'>
       <organization/>
      </author>
      <date month="April" year="1992"/>
     </front>
     <seriesInfo name='RFC' value='1321'>
    </reference>

    <reference anchor="FIPS-180-2">
     <front>
      <title>Secure Hash Standard (SHS)</title>
      <author>
       <organization>National Institute of Standards and Technology
       (NIST)</organization>
      </author>
      <date month="August" year="2002"/>
     </front>
     <seriesInfo name="FIPS PUB" value="180-2"/>
    </reference>

The references to other FIPS PUBs could do with all having the same 
format and being in numerical order.  I'd suggest replacing them with:

    <reference anchor="FIPS-46-3">
     <front>
      <title>Data Encryption Standard (DES)</title>
      <author>
       <organization>National Institute of Standards and Technology
       (NIST)</organization>
      </author>
      <date month="October" year="1999"/>
     </front>
     <seriesInfo name="FIPS PUB" value="46-3"/>
    </reference>

    <reference anchor="FIPS-186-2">
     <front>
      <title>Digital Signature Standard (DSS)</title>
      <author>
       <organization>National Institute of Standards and Technology
       (NIST)</organization>
      </author>
      <date month="January" year="2000"/>
     </front>
     <seriesInfo name="FIPS PUB" value="186-2"/>
    </reference>

    <reference anchor="FIPS-197">
     <front>
      <title>Advanced Encryption Standard (AES)</title>
      <author>
       <organization>National Institute of Standards and Technology
       (NIST)</organization>
      </author>
      <date month="November" year="2001"/>
     </front>
     <seriesInfo name="FIPS PUB" value="197"/>
    </reference>

draft-ietf-secsh-connect-24.txt:

Section 5.2: replace second paragraph with:

    After receiving this message, the recipient MAY send the given number
    of bytes more than it was previously allowed to send; the window size
    is incremented.  Implementations MUST correctly handle window sizes of
    up to 2^32 - 1 bytes.  The window MUST NOT be increased above 2^32 - 1
    bytes.

-- 
Ben Harris

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 21 Feb 2005 15:21:28 +1300

Ben Harris <[email-masked]> writes:

>I've mentioned some of these before, but all of them still apply to the set
>of drafts released on Friday.

Same here: The OpenPGP portions of section 6.6 still don't provide sufficient
information to create an interoperable implementation.  "OpenPGP compatible
binary format" for the signature could be almost anything, since OpenPGP has a
whole pile of signature components, attributes, and so on.

The easiest way to resolve this I think is to require that signatures *only*
be in "ssh-xyz format", regardless of the certificate format used (i.e. don't
tie the signature format to the key format).  I can't see any good reason for
requiring the use of complex non-SSH signature formats just because the key is
communicated using a different format, and this would also resolve the problem
with the ambiguity of the (now-deleted) X.509 format as well, since the X.509
cert format is well-defined, it's only the signature format which is
ambiguous.

So I'd propose changing the current text to:

  The signature for any DSS key (regardless of the key/certificate format
  used) is encoded as follows:

     string    "ssh-dss"
     string    dss_signature_blob

  [...]

  The signature for any RSA key (regardless of the key/certificate format
  used) is encoded as follows:

     string    "ssh-rsa"
     string    rsa_signature_blob

This finally resolves the ongoing signature format ambiguity problem, as well
as greatly reducing the complexity and implementation effort required for
parsing a pile of non-SSH signature types.

Peter.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 20 Feb 2005 22:22:12 -0500

>>>>> "Peter" == Peter Gutmann <[email-masked]> writes:

    Peter> Ben Harris <[email-masked]> writes:
    >> I've mentioned some of these before, but all of them still
    >> apply to the set of drafts released on Friday.

    Peter> Same here: The OpenPGP portions of section 6.6 still don't
    Peter> provide sufficient information to create an interoperable
    Peter> implementation.  "OpenPGP compatible binary format" for the
    Peter> signature could be almost anything, since OpenPGP has a
    Peter> whole pile of signature components, attributes, and so on.

    Peter> The easiest way to resolve this I think is to require that
    Peter> signatures *only* be in "ssh-xyz format", regardless of the
    Peter> certificate format used (i.e. don't tie the signature
    Peter> format to the key format).  I can't see any good reason for
    Peter> requiring the use of complex non-SSH signature formats just
    Peter> because the key is communicated using a different format,
    Peter> and this would also resolve the problem with the ambiguity
    Peter> of the (now-deleted) X.509 format as well, since the X.509
    Peter> cert format is well-defined, it's only the signature format
    Peter> which is ambiguous.

I would feel uncomfortable with the working group making such a
decision this late in the process.  These drafts are before the IESG.
Ideally the working group should be only need to be resolving specific
discuss comments.

The working group is apparently choosing to make somewhat broader
changes.  That's OK although it will require more review and may delay
publication.

However doing new design work seems inappropriate at this stage in the
process.  If a feature is neither sufficiently designed for
interoperable implementations nor widely implemented, drop that
feature.  You can come back and add it later either in a revision to
the core drafts or in an extension draft.

(My position is somewhat ambiguous here.  I'm the AD for this group
but I am not the shepherd for these documents.)

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Sun, 20 Feb 2005 22:24:14 -0500

It seems reasonable to replace the first reference to SHA-1 to be to
SHA-1 as defined by FIPS.  Perdhaps it is reasonable to replace the
first reference in each section.  However beyond that it seems
reasonable to refer to it as SHA-1.

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 21 Feb 2005 17:08:26 +1300

Sam Hartman <[email-masked]> writes:

>process.

I'd agree with that, but this isn't really new design work, it's just dropping
an ambiguous/underspecified format.  In other words leave the cert/key section
exactly as is, and just remove the underspecified signature format.  So I
think this meets the "drop the feature" requirement, all that's being dropped
is the use of the "xyz-pgp" signature format, leaving the "xyz-pgp" key/cert
format in place.

(Stepping back a bit, I think the problem here has always been the tying of
 each non-SSH key/cert format to a corresponding non-SSH signature format,
 even though there's no good reason for this and the non-SSH sig format is
 often under-specified.  Unifying all the signatures into a single format
 that's already universally used and widely field-tested doesn't seem like a
 major showstopper).

Peter.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Feb 2005 00:44:33 -0500

>>>>> "Peter" == Peter Gutmann <[email-masked]> writes:

    Peter> (Stepping back a bit, I think the problem here has always
    Peter> been the tying of each non-SSH key/cert format to a
    Peter> corresponding non-SSH signature format, even though there's
    Peter> no good reason for this and the non-SSH sig format is often
    Peter> under-specified.  Unifying all the signatures into a single
    Peter> format that's already universally used and widely
    Peter> field-tested doesn't seem like a major showstopper).

Your parenthetical is in fact a new design decision.  I don't believe
that making the decision to drop the PGP signature format can be made
without deciding that your parenthetical statement is the correct
design and I believe making that decision at this point in the process
is inappropriate.

--Sam

---

From: Ben Harris <[email-masked]>
Date: Mon, 21 Feb 2005 16:42:10 +0000

In article <[email-masked]> you write:
>tie the signature format to the key format).

I think this is a bad idea for the following reasons:

It forces all RSA and DSA signatures to use a SHA-1 hash, which limits them
to 80 (or maybe 69) bits of security, which is likely to be insufficient
fairly soon, and is very likely to be less than the security offered by the
MAC and cipher in use.

It forces all RSA signatures to use RSASSA-PKCS1-v1_5/SHA-1, when the same
keys might be used with other signature schemes and hashes.  This goes
against the recommendation in section 6 of RFC 3447:

   A generally good cryptographic practice is to employ a given RSA key
   pair in only one scheme.  This avoids the risk that vulnerability in
   one scheme may compromise the security of the other, and may be
   essential to maintain provable security.  While RSAES-PKCS1-v1_5
   (Section 7.2) and RSASSA-PKCS1-v1_5 (Section 8.2) have traditionally
   been employed together without any known bad interactions (indeed,
   this is the model introduced by PKCS #1 v1.5), such a combined use of
   an RSA key pair is not recommended for new applications.

It makes the use of libraries (or perhaps hardware) that encapsulate
complete signature schemes unnecessarily difficult, and perhaps impossible
in the case of secure hardware that's only willing to use a particular
signature scheme.

-- 
Ben Harris

---

From: [email-masked] (Niels Möller)
Date: 22 Feb 2005 10:52:32 +0100

> fairly soon, and is very likely to be less than the security offered by the

As long as we're signing an exchange hash computed with sha-1,
replacing the hashing that is part of the signature processing by
something stronger than sha-1 won't increase security, will it?

> keys might be used with other signature schemes and hashes.

Strictly speaking, it's possible to use the ssh-rsa *format* with
other encapsulation schemes and hashes. The format says how you put a
signature bignum into the ssh protocol, it doesn't say how that bignum
is computed or verified. There should be no problem to define a
signature algorithm "rsa-foo-sha512" and use the same format for the
generated signatures.

> complete signature schemes unnecessarily difficult, and perhaps

It's "difficult" rather than "impossible". If we ever want the
signature generated by your hardware to be verified by software, that
software must be able to decode the hardware's custom format
and get to the underlying bignum. You can do that at the sending side
(where the hardware is located), or at the receiving side (which needs
to verify the signature). And for interoperability, I think it makes a
lot of sense to do this conversion on the sender side, and have a
single format on the wire.

I think this has to be decided case by case when new certificate types
are added. But unless there are strong reasons to do differently for a
particular certificate type, I tend to agree with Peter. We don't need
more than one way to encode the bignum in an RSA (or DSA) signature.

(And for the current drafts, we just need to delete underspecified
certificate formats).

Regards,
/Niels

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 23 Feb 2005 00:36:26 +1300

>I think this is a bad idea for the following reasons:

None of those seem valid.  At the moment, the only signature mechanism is ssh-
xyz (the others are all ambiguous, so in effect they're [email-masked]
mechanisms).  Therefore if a weakness is found in the hash or signature
algorithm, all implementations will need to be fixed anyway.  Conversely, if
no weaknesses are found, there's nothing to do.  In both cases it's no change
from the current state of affairs.

(If there was some huge deployed user base that needs to be accomodated that'd
 be another issue, but debating the theoretical pros and cons of something
 that, in 23 revisions of the spec over a period of 8(?) years, nothing has
 ever used, seems rather pointless).

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 23 Feb 2005 00:44:12 +1300

[email-masked] (=?iso-8859-1?q?Niels_M=F6ller?=)
>It's "difficult" rather than "impossible". 

Just for the record, I've done SSH using both crypto coprocessors and smart
cards (I'm sure Fortezza cards were never intended to be used with SSH servers
:-), and doing anything *other* than the current "ssh-rsa" would be quite
difficult.  Everything does basic PKCS #1 v1.5 sigs, a few things do PKCS #1
OAEP, and that's about it.  So the hardware argument is strongly in favour of
"ssh-rsa", not against it.

Peter.

---

From: Ben Harris <[email-masked]>
Date: Tue, 22 Feb 2005 12:30:27 +0000 (GMT)

> something stronger than sha-1 won't increase security, will it?

True, but there will eventually be KEX methods that use better hashes than 
SHA-1.

> other encapsulation schemes and hashes.

OK.  That wasn't clear from Peter's proposal, and nor is it clear from the 
current draft.  While I think it's silly to use "ssh-rsa" to mean "some 
unspecified kind of RSA signature", I don't think it's actually dangerous.

> (And for the current drafts, we just need to delete underspecified

If they're really underspecified (to the extent that two people can't 
write interoperable implementations based solely on the spec) then yes, 
they should be deleted and specified properly in a separate draft.

-- 
Ben Harris

---

From: Ben Harris <[email-masked]>
Date: Tue, 22 Feb 2005 14:23:40 +0000

In article <[email-masked]> you write:
>algorithm, all implementations will need to be fixed anyway.

That, along with Niels Moller's reply, suggests that your interpretation of
the meaning of your suggested amendment differs from mine.  Could you thus
clarify:

Does your proposed amendment allow an ssh-rsa signature to use any scheme
other than RSASSA-PKCS1-v1_5/SHA-1?

Does your proposed amendment apply to any key format other than those
defined by [SSH-TRANS] (currently ssh-rsa and pgp-sign-rsa)?

If your answers to those questions are other than "no" and "yes"
respectively, my objections are void (though I think your proposal needs to
be clearer).

-- 
Ben Harris

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 23 Feb 2005 21:44:10 +1300

>other than RSASSA-PKCS1-v1_5/SHA-1?

Mu :-).  Currently the only scheme defined for ssh-rsa is RSASSA-PKCS1-
v1_5/SHA-1, so it's "Whatever the spec says for ssh-rsa".  If ssh-rsa is at
some point extended to allow (say) .../SHA-256 as well then it'd be
automatically accomodated.

>Does your proposed amendment apply to any key format other than those defined
>by [SSH-TRANS] (currently ssh-rsa and pgp-sign-rsa)?

Well, because it no longer ties the signature format to the key/cert format,
it allows any key format you want, but with a common (and most importantly
well-defined and universally implemented) signature format ssh-rsa (or dsa).
So instead of:

  Key              Sig

  ssh-rsa          ssh-rsa
  pgp-sign-rsa     pgp-sign-rsa
  x509-sign-rsa    x509-sign-rsa
  spki-sign-rsa    spki-sign-rsa
  wibble-sign-rsa  wibble-sign-rsa

where everything in the "Sig" column except ssh-rsa is
underspecified/ambiguous and therefore more or less impossible to achieve
interoperability on, it'd be:

  Key              Sig

  ssh-rsa          ssh-rsa
  pgp-sign-rsa     ssh-rsa
  x509-sign-rsa    ssh-rsa
  spki-sign-rsa    ssh-rsa
  wibble-sign-rsa  ssh-rsa

with the single universal sig format and any key format you want.

Peter.

---

From: Ben Harris <[email-masked]>
Date: Wed, 23 Feb 2005 11:14:08 +0000

>automatically accomodated.

That's a "no" for my purposes.

>well-defined and universally implemented) signature format ssh-rsa (or dsa).

That doesn't answer my question.  I'll try rephrasing:

Imagine I've got an RSA-based authentication system, with its own
certificate format, so I define a [email-masked] public-key format. 
It happens that my authentication system uses its keys with RSASSA-PSS
internally.

1: Am I required to use the "ssh-rsa" signature format?
2: Am I required to use RSASSA-PKCS1-v1_5/SHA-1?

>underspecified/ambiguous

Why is it obviously the case that all future RSA signature formats (which I
assume to be represented by "wibble-sign-rsa") are going to be
underspecified or ambiguous?

-- 
Ben Harris

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 24 Feb 2005 01:13:29 +1300

>That's a "no" for my purposes.

Well obviously it's a no because there's no other format defined, so anything
that uses ssh-rsa with other than RSASSA-PKCS1-v1_5/SHA-1 is in violation of
the spec.  Your question was the equivalent of "Have you stopped beating your
wife yet", which was why I answered "Mu", and then qualified it by saying that
if ssh-rsa was extended to allow anything else then using that would be OK.

>Imagine I've got an RSA-based authentication system, with its own certificate
>format, so I define a [email-masked] public-key format. It happens
>that my authentication system uses its keys with RSASSA-PSS internally.
>

No, you can use whatever you want, although unless you use ssh-rsa you're not
going to be able to talk to anything else (obviously, that's what's implied
by the [email-masked] format).

>2: Am I required to use RSASSA-PKCS1-v1_5/SHA-1?

Since RSASSA-PKCS1-v1_5/SHA-1 is the only format defined for ssh-rsa, I guess
the answer is yes (see my comment above).  I guess you can use anything you
want in practice and still call it ssh-rsa, but your implementation won't
interoperate with anything else.  OTOH if you wanted to use (say) RSA-PSS, you
could do by specifying [email-masked] for the sig format.

>assume to be represented by "wibble-sign-rsa") are going to be underspecified
>or ambiguous?

It isn't obvious, but to date (through all 23 revisions of the spec) they've
been underspecified and ambiguous.  I have no idea what future formats will
be, however since no-one's managed to sort it out in 8(?) years of work and
polls on the list have indicated that no-one's really interested in sorting it
out (see e.g. the discussion over what the X.509 sig format is from a while
back), I don't hold out much hope.  Since everything except ssh-rsa has had to
be removed over time because no-one's sure of the format for signatures,
requiring that people use the existing universally-implemented ssh-rsa
signatures with all of the removed formats would solve this problem.

Peter.

---

From: Ben Harris <[email-masked]>
Date: Wed, 23 Feb 2005 12:36:12 +0000

>by the [email-masked] format).

In that case, I don't think I have any objection to your proposal, though I
still think a better approach at this stage would be to simply remove all
mention of OpenPGP keys and leave their handling to be defined properly in a
separate RFC.

-- 
Ben Harris

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 24 Feb 2005 02:12:24 +1300

Ben Harris <[email-masked]> writes:

>I still think a better approach at this stage would be to simply remove all

In a perfect world I'd agree that this would be the way to do it, however
given the lack of interest shown in this in the past I think this would be a
kind of de facto consignment to oblivion of all the other formats.  The
advantage of doing it now would be that it only requires a few words changed
here and there, rather than an entire new RFC that (most probably) no-one will
ever be motivated to write (just thinking of my own code, it'd take me about 5
minutes to add an "x509-whatever" or "pgp-whatever" entry to the SSH cert
decoding table, but a great many hours to do an RFC to specify it).  It's a
pay-me-now/pay-me-later thing, I'd rather change a sentence or two now than
have to do an entire RFC later.

The only possible ambiguity I can see with the use of X.509/OpenPGP/SPKI keys
is whether you include a single key/cert or throw in an entire WoT/cert
chain/whatever bundle, so the text would have to be explicit in saying that
only a single key/cert is present, not an arbitrary collection of stuff.  I
guess if you want to be really picky you could go on for pages and pages about
which sort of cert/key attributes need to be present and how to determine
whether they're valid for the server being connected to and how to handle
revocation checking and let's convene a subcommittee to report back on this in
six months, but since the current way of doing it is just a raw public key
with no attributes at all, I think a sentence like "Determining whether a key
or certificate is valid for its intended purpose is a local configuration
issue" would be the best way out.

Either that or just drop all foreign formats on grounds of total
incomprehensibility and no-one's really interested anyway.

Peter.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 23 Feb 2005 08:40:23 -0500

On Thursday, February 24, 2005 02:12:24 AM +1300 Peter Gutmann 
<[email-masked]> wrote:

>> I still think a better approach at this stage would be to simply remove
>> all mention of OpenPGP keys and leave their handling to be defined
>> properly in a separate RFC.
>
> given the lack of interest shown in this in the past I think this would
> be a kind of de facto consignment to oblivion of all the other formats.
> The advantage of doing it now would be that it only requires a few words
> changed here and there, rather than an entire new RFC that (most
> probably) no-one will ever be motivated to write (just thinking of my own
> code, it'd take me about 5 minutes to add an "x509-whatever" or
> "pgp-whatever" entry to the SSH cert decoding table, but a great many
> hours to do an RFC to specify it).  It's a pay-me-now/pay-me-later thing,
> I'd rather change a sentence or two now than have to do an entire RFC
> later.

> incomprehensibility and no-one's really interested anyway.

Ah, now you have the right idea.

If no one cares enough about these to write up clear, unambiguous specs 
that spell out all the details required for secure, interoperable 
implementations, I can't imagine why anyone would care enough to actually 
implement and test them.

If we don't have two interoperable implementations of these key types, they 
will have to be dropped before we can move to draft.  If we don't believe 
there are ever going to be two interoperable implementations, we might as 
well drop them _now_, and save all the nastiness about how massively 
underspecified they are.

-- Jeff

---

From: [email-masked] (Niels Möller)
Date: 24 Feb 2005 12:45:54 +0100

[email-masked] (Peter Gutmann) writes:

> only a single key/cert is present, not an arbitrary collection of
> stuff.

At least for spki, that doesn't make much sense. The model is that the
server uses only a flat acl list (analogous to "root cert list" for
x.509), and it's the client's responsibility to provide whatever
certificates are needed to prove that it is authorized. And the
colection shouldn't be arbitrary either, it should provide precisely
the information needed, and in the right order, for the spki machinery
to derive the authorization for the given key.

Back to signature formats, I think one reason it makes sense to use an
ssh-specific format for all signatures, is that certificate standards
tend to focus on the certificates, and about the only signatures that
are specified in detail are signatures on certificate. How a certified
key is to be used by applications is left open, since all applications
but signing other certificates are irrelevant to interoperability in
the creation and verification of the certificates.

By using ssh-rsa and ssh-dss signature formats (and also spelling out
precisely which data should be signed), we say how certified keys are
to be used in our application, ssh.

/Niels

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 25 Feb 2005 06:16:15 -0800 (PST)

Hi,

On Sun, 20 Feb 2005, Ben Harris wrote:

> I've mentioned some of these before,

Sorry, I must have missed them.

> but all of them still apply to the

OK.

> hash, as defined in [FIPS-180-2],".

Like Sam says, the first occurance should be sufficient.

> "according to the RSASSA-PKCS1-v1_5 scheme of [RFC3447]".

OK.

> Section 15.1: delete references [RFC2693] and [RFC3280].

Good catch.

>      <seriesInfo name='RFC' value='1321'>

The references for RFCs are already done.
  http://xml.resource.org/public/rfc/bibxml/
I just have to pull that (actually just the tar) and then give an
"include" in the document.
  <?rfc include="./references/reference.RFC.1321.xml"?>

>      <seriesInfo name="FIPS PUB" value="180-2"/>

Unlike the RFCs, there are not too many FIPS pubs in the repository
  http://xml.resource.org/public/rfc/bibxml2/

> format and being in numerical order.  I'd suggest replacing them with:

OK.

>      <seriesInfo name="FIPS PUB" value="46-3"/>

I think the seriesInfo should be spelled out:

<reference anchor='FIPS-46-3'>
<front>
<title>Data Encryption Standard (DES)</title>
<author>
<organization>National Institute of Standards and
Technology</organization>
</author>
<date month='October' year='1999'/>
</front>
<seriesInfo name='Federal Information Processing Standards Publication'
value='46-3' />
</reference>

and I'll make them all consistent.

>     up to 2^32 - 1 bytes.  The window MUST NOT be increased above 2^32 - 1

OK.

Thanks,
Chris