Subject: Re: DISCUSS comments on publickeyfile-09

From: Joseph Galbraith <[email-masked]>
Date: Tue, 04 Oct 2005 13:13:02 -0600

>    The examples in section 3.6 do not seem to match the key blob
>    description in [I-D.ietf-secsh-transport], section 6.6, which says:
>    >
>    > The key type MUST always be explicitly known (from algorithm
>    > negotiation or some other source).  It is not normally included in
>    > the key blob.

Argh....

This statement in the transport draft is wrong!
(Unless I'm somehow not understanding what
it means.)

"ssh-dss" and "ssh-rsa" keys (the only keys actually
specified by the transport, both specify the key
type in the key blob.

As in (from 6.6 in transport)

   The "ssh-dss" key format has the following specific encoding:

       string    "ssh-dss"
       mpint     p
       mpint     q
       mpint     g
       mpint     y

Or (again 6.6):

    The "ssh-rsa" key format has the following specific encoding:

       string    "ssh-rsa"
       mpint     e
       mpint     n

>    But in this context, it is needed.  This document should make this
>    clear with a MUST statement.  Note that it is included in each of
>    the examples.  I base64 decoded them and checked.

It is only there because the transport draft
specifies that ssh-dss and ssh-rsa key blobs have it.

The x.509 draft also specifies that it should be there
for x.509 keys.

The [email-masked] agent protocol requires it to be
there in order to operate correctly (though the expired
agent draft from the working group does not.)

If it is not too late, I think that paragraph should
be removed from the transport draft.  But it is probably
too late.

Thanks,

Joseph

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 04 Oct 2005 13:35:26 -0600

> Section 3, second paragraph, and elsewhere: "MUST NOT be longer than 72
> bytes".  "bytes" is an imprecise term.  Do they really mean "8-bit ASCII
> characters", octets, or are 9-bit bytes as implemented on older hardware
> architectures also acceptable?
> 
> Section 3.4 uses the term "characters" to describe a line length
> limitation.
> Consistency would be good.

I agree that consistency would be good.

We do specify that that header-values MUST be encoded
in UTF8.  So changing to allow 72 characters could
mean a significant growth in the number of bytes allowed
on a line (*3 for Japanese text, for example.)

8-bit ASCII characters is close, except for those
UTF-8 header values.

What if we specified "MUST NOT be longer than 72 8-bit
bytes?"

Thanks,

Joseph

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 04 Oct 2005 13:54:31 -0600

>    The introduction to this document is very lightweight.  Please expand
>    it to provide some context.  At a minimum, this needs to say that the
>    document is about the SSH protocol and the role of public keys.  It
>    is also desirable to cover the trust model, explaining why these
>    files are very important.
> 
>    The introduction should be expanded to discuss fingerprints and how
>    they are used in SSH.

Is this better:

   The SSH protocol supports the use of public/private key pairs
   in order to perform authentication (public-key authentication.)
   However, in order to use public-key authentication in the SSH
   protocol, public keys must first be exchanged between client
   and server.

   This document formally describes an existing public-key file
   format which can be used with any of the common existing file
   transfer mechanisms in order to exchange public keys.

   The SSH protocol also uses public/private key pairs to
   authenticate the server.  In this scenario, it is important
   to verify that the public key provided by the server is
   indeed the server's public-key.

   This document describes a mechanism for creating a short text
   string that uniquilly represents a public-key (fingerprinting)
   for use in manually comparing public keys.

>    In section 3.6, please change "me@myhost" to "[email-masked]".

Done.

>    The last paragraph of the security considerations needs to be
>    expanded to provide a bit of context.  MD5 has some known weakness,
>    but they are not a problem in this situation because ...

Is this better?

   The public-key fingerprint method presented here relies on
   the MD5 hash, which is known to have certain weaknesses
   regarding it's collision-resistance; however, the particular
   use made of MD5 here depends solely on it's 2nd-preimage
   resistance, not on it's collision-resistance.

   MD5 is used here for historical reasons.

Thanks,

Joseph

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 04 Oct 2005 14:48:13 -0600

Done.  Once the rest of the DISCUSSes are resolved,
I'll spin -10.

Thanks,

Joseph

Scott Hollenbeck wrote:
> That would be fine with me.  Please check for other uses of the "byte" word,
> though, too.
> 
> -Scott-
> 
>> -----Original Message-----
>> From: Joseph Galbraith [mailto:[email-masked]] 
>> Sent: Tuesday, October 04, 2005 3:35 PM
>> To: Bill Sommerfeld
>> Cc: [email-masked]; Scott Hollenbeck; Sam Hartman
>> Subject: Re: DISCUSS comments on publickeyfile-09
>>
>>> Section 3, second paragraph, and elsewhere: "MUST NOT be 
>> longer than 
>>> 72 bytes".  "bytes" is an imprecise term.  Do they really 
>> mean "8-bit 
>>> ASCII characters", octets, or are 9-bit bytes as 
>> implemented on older 
>>> hardware architectures also acceptable?
>>>
>> We do specify that that header-values MUST be encoded in 
>> UTF8.  So changing to allow 72 characters could mean a 
>> significant growth in the number of bytes allowed on a line 
>> (*3 for Japanese text, for example.)
>>
>> What if we specified "MUST NOT be longer than 72 8-bit bytes?"
>>
>> Thanks,
>>
>> Joseph
>>
>>
>>
> 
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 04 Oct 2005 16:51:55 -0400

It is not too late to fix the [I-D.ietf-secsh-transport] document if the WG 
consensus is that the paragraph is incorrect.  It is up to the WG chair to 
work with Sam and I to get this changed while it is still in the RFC Editor 
queue if that is the will of the WG.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 04 Oct 2005 17:04:48 -0400

Joseph:

The replacement introduction looks good, but I have a few editorial 
suggestions below.

>   in order to perform authentication (public-key authentication.)

... perform authentication based on public-key cryptography.

>   string that uniquilly represents a public-key (fingerprinting)

... that uniquely represents a particular public key, called fingerprinting.

>   for use in manually comparing public keys.

The replacement security considerations text looks good, but I have a few 
editorial suggestions below.

>   the MD5 hash, which is known to have certain weaknesses

... MD5 one-way hash function, which ...

Russ

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 04 Oct 2005 16:03:35 -0600

Done...

Thanks,

Joseph

Russ Housley wrote:
> The replacement security considerations text looks good, but I have a
> few editorial suggestions below.
>

---

From: der Mouse <[email-masked]>
Date: Tue, 4 Oct 2005 18:49:01 -0400 (EDT)

>    MD5 is used here for historical reasons.

s/it's/its/ in all three occurrences.  I'd also
s/collision-resistance/collision resistance/, but that's less
important.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 4 Oct 2005 16:15:09 -0400

-Scott-

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 04 Oct 2005 17:06:31 -0600

Done.

Thanks as usual for the review.

Joseph

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 04 Oct 2005 17:10:58 -0600

Comments from others?

>    Certificates and public keys are encoded as follows:
>       string    certificate or public key format identifier
>       byte[n]   key/certificate data
> 

The first paragraph definitely seems in conflict with
the second, since the second clearly states that
a public key or certificate has a type identifier...
add to that the fact that all the currently
defined public-key types also include the
identifier...

I think we should strike the first paragraph.

Thoughts?

Thanks,

Joseph

Russ Housley wrote:
> It is not too late to fix the [I-D.ietf-secsh-transport] document if the
> WG consensus is that the paragraph is incorrect.  It is up to the WG
> chair to work with Sam and I to get this changed while it is still in
> the RFC Editor queue if that is the will of the WG.
> 
> Russ
>