From owner-ietf-ssh@clinet.fi Fri Sep 1 08:35:28 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10325 for ; Fri, 1 Sep 2000 08:35:27 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id NAA18739 for ietf-ssh-outgoing; Fri, 1 Sep 2000 13:28:36 +0300 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id NAA18733 for ; Fri, 1 Sep 2000 13:28:33 +0300 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id NAA22738; Fri, 1 Sep 2000 13:25:03 +0300 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14767.33790.707474.768304@asgard.tky.hut.fi> Date: Fri, 1 Sep 2000 13:25:02 +0300 (EEST) To: IETF-Secsh List Subject: HMACs X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit The transport draft doesn't specify key lengths to the hmac-algorithms. Only the digest length is shown. According to RFC-2104: --snip-- The key for HMAC can be of any length (keys longer than B bytes are first hashed using H). However, less than L bytes is strongly discouraged as it would decrease the security strength of the function. Keys longer than L bytes are acceptable but the extra length would not significantly increase the function strength. --snap-- So, a key longer or shorter than the digest is considered bad. I think this should be fixed in the draft. Would this sound ok: The key length used by the hmac MUST be the same as the digest length. Reason I bumped into this is that OpenSSH uses the digest lengths as key lengths, and our implementation just gave the hmac a 128-bit key. An interoperability problem, that is. Bill, what's up with the notes from the Pittburgh IETF? -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Fri Sep 1 10:43:27 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13028 for ; Fri, 1 Sep 2000 10:43:26 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA22605 for ietf-ssh-outgoing; Fri, 1 Sep 2000 15:58:59 +0300 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA22594 for ; Fri, 1 Sep 2000 15:58:55 +0300 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id OAA16184; Fri, 1 Sep 2000 14:58:41 +0200 (MET DST) Date: Fri, 1 Sep 2000 14:58:41 +0200 From: Markus Friedl To: Sami Lehtinen Cc: IETF-Secsh List Subject: Re: HMACs Message-ID: <20000901145841.A15938@faui02.informatik.uni-erlangen.de> References: <14767.33790.707474.768304@asgard.tky.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <14767.33790.707474.768304@asgard.tky.hut.fi>; from sjl@iki.fi on Fri, Sep 01, 2000 at 01:25:02PM +0300 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Fri, Sep 01, 2000 at 01:25:02PM +0300, Sami Lehtinen wrote: > So, a key longer or shorter than the digest is considered bad. I think > this should be fixed in the draft. s/should/MUST/ > The key length used by the hmac MUST be the same as the digest length. yes, this is what i have been asking before, both on this list and on bugs@ssh.com but it seems that noone did care before. -markus From owner-ietf-ssh@clinet.fi Fri Sep 1 13:44:29 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17065 for ; Fri, 1 Sep 2000 13:44:28 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA12069 for ietf-ssh-outgoing; Fri, 1 Sep 2000 19:06:33 +0300 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA12066 for ; Fri, 1 Sep 2000 19:06:31 +0300 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15308; Fri, 1 Sep 2000 09:06:24 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA24108; Fri, 1 Sep 2000 12:06:18 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e81G5nT108311; Fri, 1 Sep 2000 12:05:49 -0400 (EDT) Message-Id: <200009011605.e81G5nT108311@thunk.east.sun.com> From: Bill Sommerfeld To: Sami Lehtinen cc: IETF-Secsh List Subject: Re: HMACs In-reply-to: Your message of "Fri, 01 Sep 2000 13:25:02 +0300." <14767.33790.707474.768304@asgard.tky.hut.fi> Reply-to: sommerfeld@east.sun.com Date: Fri, 01 Sep 2000 12:05:49 -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > Bill, what's up with the notes from the Pittburgh IETF? working on it now.. sorry for the delay. - Bill From owner-ietf-ssh@clinet.fi Fri Sep 1 21:34:44 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24922 for ; Fri, 1 Sep 2000 21:34:42 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA05258 for ietf-ssh-outgoing; Sat, 2 Sep 2000 02:50:55 +0300 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA05255 for ; Sat, 2 Sep 2000 02:50:53 +0300 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26602 for ; Fri, 1 Sep 2000 16:50:50 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA06650; Fri, 1 Sep 2000 19:50:49 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e81NoJT108944; Fri, 1 Sep 2000 19:50:19 -0400 (EDT) Message-Id: <200009012350.e81NoJT108944@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi cc: minutes@ietf.org Subject: minutes from the SECSH working group meeting at the 48th IETF Reply-to: sommerfeld@east.sun.com Date: Fri, 01 Sep 2000 19:50:19 -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Minutes of the secsh working group Wednesday, August 2, 2000 Notes taken by Jeremey Barrett , revised by Bill Sommerfeld Bill apologized for arranging the secsh meeting on such short notice. Note that the schedule in charter badly blown (all dates are in 1997). Working group status: Bill took over as chair shortly before this IETF meeting. The core set of 4 docs are all heavily inderdependent and need to advance as a unit. In Dec '97, a last call was put out on these documents; a couple comments came in, but no action was taken in response to the comments, and the documents were not submitted to the IESG. In theory we could do last call again now and just go, but we're already aware of some issues which exist, so we may as well fix them first, and advance the core documents onto the standards track, then move on to new work. Bill looked through archive for issues, though it was mind-numbing work and may have missed a few. Open issues/proposed resolutions: draft-ietf-secsh-architecture-05.txt dangling reference to ssh-agent draft - rip out until agent draft exists. anti-dns language in section 4.1 - rip out section 4.1; dead code. iana considerations section ok? - waiting for answer from AD draft-ietf-secsh-transport-07.txt optimistic algorithm negotiation - discuss on list. eliminating redundant length fields - just do it. add ssh-rsa key type - just do it. arcfour - add cautionary text key stretching clamps entropy to hash size - ok as is given current threat models, but document as such packet size fuzz factor - document 35000 as arbitrary value larger than uncompressed size secrecy of exchange hash - document that its best to keep it secret Should concatenated string encoding specify length of each string? (transport, section 6) - [chair couldn't find context; will take to list] DH parameter selection clarification - [chair couldn't find context; will take to list] dangling references to pkix, spki - both are now rfcs; correct references. draft-ietf-secsh-userauth-07.txt any certificate implementation experience? - none yet, but that's ok for now. draft-ietf-secsh-connect-07.txt signal encoding - extend format, include optional string with signal name w/o SIG prefix. SIGBUS -> "BUS" need references to X11, POSIX drafts - just add them. ssh agent forwarding dangling references - remove for now until agent draft appears. ---- Kerberos Authentication (Tatu Ylonen) Two new auth methods: kerberos - Generate Kerberos AP_REQ Server must be able to parse and decrypt request in order to accept auth. kerberos-tgt Passes ticket-granting ticket to server in CREDS message from c->s Server MUST use the tgt to create a new ticket to validate it Server MAY store it in the credentials cache First keeps server from getting access to tgt, second gives server tgt Password method no protocol change SHOULD allow Kerb password and SHOULD store tgt in credentials cache User names with realms In addition to basic user name, could be user@realm The user name MUST be mapped to local name by the server if it supports Kerb. Might need to change draft to allow @ % might be used instead of @ on in client and then translated, since you can do ssh blah@foo Folks familiar with kerberos picked a few nits with the proposal. - protocol needs to use mutual authentication. - credential forwarding needs to either happen after mutual authentication or be protected with the ticket's key. - don't need a principal name outside the ticket; just leave login name alone questions: why not GSSAPI? - misc implementation/portability issues. (can't do what ssh needs with current mechanism-independant gssapi) action: tatu to write up an independant draft based on feedback and publish. Other new features: (MUST be independant drafts; don't want to hold up core drafts.) Authentication agent An old draft exists, but must be checked against implementations, etc. Won't take long to write a draft, just matter of getting to it. -------------------------------- File transfer Current sftp draft is not in any state. sftp protocol needs to be documented, reviewed by the working group. file listing format should take a look at what the FTP WG did for directory listings. --------------------------------- "How to write an auth method" Suggestion that since there is interest in new auth methods, there should be some text on how to do this somewhere. Bill: if someone wants to write one, please do ---------------------------------- DH param negotiation Draft has boilerplate problems. Author couldn't make it this week (Nils Provos). No comments. --------------------------------- Text file key exchange format info doc For pubkeys and private keys to allow portability of keys between implementations. Jeff van Dyke volunteered to put together a summary of the 4 variations out there for the list. ---------------------------------------------- Problems with SSHv1 There was a request to publish a spec for sshv1 as an IETF document (probably going directly to Historic status). Tatu proposed, as an alternative, documenting "why not SSHv1" as an Informational document. ------------------------------------------ Improvided password auth EKE/SPEKE/SRP interest which ties the password a bit better into the crypto and less succeptible to dictionaries. A volunteer exists to write a draft on this. Should look at these on the list. ------------------------------------------------ il8n of usernames A comment to the list was made that multiple representations could happen, do we need canonicalization. Niels Moller suggested waiting for il8n strategy from the DNS people and using that. Bill: other people are attacking this and what they do will probably work, the main problem with at least one draft is case sensitivity (especially with DNS stuff) Tatu: If you want to make username something other than canonicalized binary crud, you will have to add something to identify which encoding it's in, might make sense to add it at this point. If we add it now, the installed base might be able to handle it when il8n is actually ready. Bill: for compatibility we could add more magic strings for the tagged username format Tatu: canonicalization could happen at client, and require NO changes to draft Bill: anyone know of any mine fields here? Comment: client would need unicode database Comment: is there a reason UTF-8 wasn't used? Tero: there are implementations that use "just binary data" A bunch of UTF-8 discussion... Comment: possible large sizes, etc Ted: classic objection to UTF-8 is byte extension, but for usernames, not a big deal. The big deal is il8n hell. Tero: I think canonicalization should be done at server, since it knows internal format it wants to use. Bill: take this to the list ======================================================== Charter no particular revisions appear to be needed until we decide on what extensions we want to work on. -------------------------------------- Schedule Sep 00 Finalization of core drafts Oct 00 Last calls Oct 00 Submit core drafts to IESG Oct 00 Determine schedule for extensions Nov 00 Submit extension drafts for discussion Dec 00 Meet in SD Sep 01 Submit core drafts for publication as draft standard Discussion on how long we need for extension drafts; we can discuss that once the core drafts are finalized. Authors interested in working on internet-drafts for extensions should get in touch with the WG chair. Extension drafts should be done at least a month before the next WG meeting so that we have time to look at them and discuss them on the list before the meeting. - Bill From owner-ietf-ssh@clinet.fi Sat Sep 2 18:38:53 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17067 for ; Sat, 2 Sep 2000 18:38:52 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA29013 for ietf-ssh-outgoing; Sat, 2 Sep 2000 23:34:23 +0300 Received: from raeburn.org (r93aag001418.sbo-smr.ma.cable.rcn.com [209.6.180.209]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA29004 for ; Sat, 2 Sep 2000 23:34:19 +0300 Received: (from raeburn@localhost) by raeburn.org (8.8.8/8.6.9) id QAA07621; Sat, 2 Sep 2000 16:34:16 -0400 (EDT) X-Authentication-Warning: raeburn.org: raeburn set sender to raeburn@raeburn.org using -f To: IETF-Secsh List Subject: Re: HMACs References: <14767.33790.707474.768304@asgard.tky.hut.fi> From: Ken Raeburn Date: 02 Sep 2000 16:34:10 -0400 In-Reply-To: Sami Lehtinen's message of "Fri, 1 Sep 2000 13:25:02 +0300 (EEST)" Message-ID: Lines: 26 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Sami Lehtinen writes: > According to RFC-2104: > --snip-- > The key for HMAC can be of any length (keys longer than B bytes are > first hashed using H). However, less than L bytes is strongly > discouraged as it would decrease the security strength of the > function. Keys longer than L bytes are acceptable but the extra > length would not significantly increase the function strength. > --snap-- As an aside, I think the quoted text only applies if the key space is dense, at least for certain attack modes. More to the point, it'd be the number of possible keys (up to 2**L), not the number of bits in a particular representation. (Would spelling out the numerical value of a 4-byte key as English text really improve the key strength just by making it longer?) > The key length used by the hmac MUST be the same as the digest length. Why require that it can be no longer? Even if the HMAC strength levels off somewhat (completely?) after a certain number of bits, is that reason to disallow longer keys? "...MUST be at least as long as..." ? Ken From owner-ietf-ssh@clinet.fi Sat Sep 2 23:12:38 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20349 for ; Sat, 2 Sep 2000 23:12:37 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id EAA10486 for ietf-ssh-outgoing; Sun, 3 Sep 2000 04:26:19 +0300 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id EAA10482 for ; Sun, 3 Sep 2000 04:26:18 +0300 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id EAA24092; Sun, 3 Sep 2000 04:22:33 +0300 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14769.42968.909135.523767@asgard.tky.hut.fi> Date: Sun, 3 Sep 2000 04:22:32 +0300 (EEST) To: Ken Raeburn Cc: IETF-Secsh List Subject: Re: HMACs In-Reply-To: References: <14767.33790.707474.768304@asgard.tky.hut.fi> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Ken Raeburn, on September 2. 2000, wrote: : > The key length used by the hmac MUST be the same as the digest length. : : Why require that it can be no longer? Even if the HMAC strength : levels off somewhat (completely?) after a certain number of bits, is : that reason to disallow longer keys? : : "...MUST be at least as long as..." ? You must state the key length somewhere, otherwise you end up with uninteroperable implementations (as it is now). We can't just say ("SHOULD be something like...") as everyone would implement that differently. RFC-2104 has some points on the key length being longer than the digest length, I suggest you read it. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Sun Sep 3 08:03:49 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08300 for ; Sun, 3 Sep 2000 08:03:48 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id NAA01341 for ietf-ssh-outgoing; Sun, 3 Sep 2000 13:07:48 +0300 Received: from folly.informatik.uni-erlangen.de (nbgdi5-145-253-148-017.arcor-ip.net [145.253.148.17]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id NAA01336 for ; Sun, 3 Sep 2000 13:07:45 +0300 Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 42F2412DA; Sun, 3 Sep 2000 12:07:15 +0200 (CEST) Date: Sun, 3 Sep 2000 12:07:15 +0200 From: Markus Friedl To: Tero Kivinen Cc: Sami Lehtinen , IETF-Secsh List Subject: Re: HMACs Message-ID: <20000903120715.B28887@folly.informatik.uni-erlangen.de> References: <14767.33790.707474.768304@asgard.tky.hut.fi> <20000901145841.A15938@faui02.informatik.uni-erlangen.de> <14769.31115.453744.702225@hutcs.cs.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <14769.31115.453744.702225@hutcs.cs.hut.fi>; from kivinen@mail.niksula.cs.hut.fi on Sun, Sep 03, 2000 at 01:09:36AM +0300 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Sun, Sep 03, 2000 at 01:09:36AM +0300, Tero Kivinen wrote: > Markus Friedl writes: > > On Fri, Sep 01, 2000 at 01:25:02PM +0300, Sami Lehtinen wrote: > > > So, a key longer or shorter than the digest is considered bad. I think > > > this should be fixed in the draft. > > s/should/MUST/ > > I don't think it is MUST. Changing it does not really offer any more > security, as the key length is already long enough and the > Diffie-Hellman doesn't provide that much entropy. > > Changing it is again incompatible change to the protocol that will > break implementations which have implemented the SHA1 HMAC as defined > in the drafts. > > The current draft quite clearly says that if we have algorithm that is > using variable length keys then we use 128 bits for the key. The HMACs > do have variable length keys, so currently it would be agains the > draft to use any other key length for HMACs. so why does twofish use 256 bits? why specfify the size? why use a hmac in a way that is against current practice? rfc2104 clearly states: "The key for HMAC can be of any length ... However, less than L bytes is strongly discouraged ..." (L=160 bits for sha1). From owner-ietf-ssh@clinet.fi Mon Sep 4 05:06:32 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01269 for ; Mon, 4 Sep 2000 05:06:32 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id KAA21337 for ietf-ssh-outgoing; Mon, 4 Sep 2000 10:15:55 +0300 Received: from raeburn.org (r93aag001418.sbo-smr.ma.cable.rcn.com [209.6.180.209]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id KAA21320 for ; Mon, 4 Sep 2000 10:15:53 +0300 Received: (from raeburn@localhost) by raeburn.org (8.8.8/8.6.9) id DAA19819; Mon, 4 Sep 2000 03:15:50 -0400 (EDT) X-Authentication-Warning: raeburn.org: raeburn set sender to raeburn@raeburn.org using -f To: IETF-Secsh List Subject: Re: HMACs References: <14767.33790.707474.768304@asgard.tky.hut.fi> <14769.42968.909135.523767@asgard.tky.hut.fi> From: Ken Raeburn Date: 04 Sep 2000 03:15:50 -0400 In-Reply-To: Sami Lehtinen's message of "Sun, 3 Sep 2000 04:22:32 +0300 (EEST)" Message-ID: Lines: 41 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Sami Lehtinen writes: > You must state the key length somewhere, otherwise you end up with > uninteroperable implementations (as it is now). We can't just say > ("SHOULD be something like...") as everyone would implement that > differently. I just looked at the context further than I did before. I was thinking key exchange, but that's not the case here, looks like you're talking about the keys generated by both parties from the exchanged data. So yes, the key length needs to be specified somewhere, in the protocol data or the protocol spec. > RFC-2104 has some points on the key length being longer than the > digest length, I suggest you read it. I did look at it before sending my comments, and it says relatively little on this point that I could find. The first paragraph of section 3 says longer keys "would not significantly increase" the HMAC strength, not that they "would not at all increase" it, and doesn't go into any details of what the difference might be, if any. It then goes on to indicate circumstances -- weak randomness in the key data, which I would think would include any structure or predictability to the values, say if not all 2**N values could actually be generated because K is computed using a modulus slightly less than 2**N -- in which longer keys *can* improve the strength. Hence my question about allowing longer keys than the minimum. I'm not a cryptographer, though, and I'm still familiarizing myself with the paper by Bellare, Canetti, and Krawczyk that RFC 2104 refers to. And I haven't figured out anything about just how weakness in the random number generators used in implementations might affect the quality of the key exchanged, or whether generating longer keys through multiple hashes would help the HMAC at all in such a case. Hence my phrasing of my original comments as questions. :-) If longer keys don't help at all, fine. But RFC 2104 doesn't say that. Ken From owner-ietf-ssh@clinet.fi Wed Sep 6 07:13:24 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07638 for ; Wed, 6 Sep 2000 07:13:23 -0400 (EDT) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA07102 for ietf-ssh-outgoing; Wed, 6 Sep 2000 12:20:45 +0300 Received: from toto.oz.is (toto.oz.is [193.4.211.170]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA07082 for ; Wed, 6 Sep 2000 12:20:42 +0300 Received: from kansas.intranet.oz.is (scarecrow.oz.is [193.4.211.95]) by toto.oz.is (8.9.3/8.9.3) with ESMTP id JAA18671 for ; Wed, 6 Sep 2000 09:26:05 GMT Received: from kansas.intranet.oz.is (scarecrow.oz.is [193.4.211.95]) by toto.oz.is (8.9.3/8.9.3) with ESMTP id JAA18645 for ; Wed, 6 Sep 2000 09:23:32 GMT X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000 MIME-Version: 1.0 Subject: A comment on certificate-based server authentication and multiple DNS names To: Message-ID: Date: Wed, 6 Sep 2000 09:15:44 +0000 X-MIMETrack: Serialize by Router on OZ-ICE/OZ-Inc(Release 5.0.3 (Intl)|21 March 2000) at 06.09.2000 09:16:08 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I have a comment on current draft as it relates to certificate-based server authentication. As the protocol stands today, the combined diffie-hellman-group1-sha1 key-exchange and server authentication algorithms will purportedly extend to cover certificate-based signature schemes. There is however a problem when a single server host may respond to more than one DNS name. This problem is analogous to the one in initial versions of the HTTP protocol, which made it impossible to serve multiple domains from a single IP number. Now, it would be entirely possible to devise a new key exchange scheme, which would carry the DNS name the client intends to connect to, in order to allow the server host to select the corresponding private key and certificate to respond with. However, it seems that it might be possible to extend the current diffie-hellman-group1-sha1 in a backwards compatible manner to include an optional string parameter in the DH_INIT packet: byte SSH_MSG_KEXDH_INIT mpint e string server dns name (optional) Comments? From owner-ietf-ssh@clinet.fi Wed Sep 6 09:20:26 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11412 for ; Wed, 6 Sep 2000 09:20:25 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA08285 for ietf-ssh-outgoing; Wed, 6 Sep 2000 14:34:54 +0300 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id OAA08269 for ; Wed, 6 Sep 2000 14:34:51 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 7092024012EC for ; Wed, 6 Sep 2000 13:34:51 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id NAA01873; Wed, 6 Sep 2000 13:34:51 +0200 (MET DST) To: Subject: Re: A comment on certificate-based server authentication and multiple DNS names References: From: nisse@lysator.liu.se (Niels Möller) Date: 06 Sep 2000 13:34:50 +0200 In-Reply-To: owner-ietf-ssh@clinet.fi's message of "Wed, 6 Sep 2000 09:15:44 +0000" Message-ID: Lines: 43 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk owner-ietf-ssh@clinet.fi writes: > There is however a problem when a single server host may respond to > more than one DNS name. This problem is analogous to the one in > initial versions of the HTTP protocol, which made it impossible to > serve multiple domains from a single IP number. I don't see this as big problem; I don't think people usually do large scale "virtual hosting" for ssh. There's no problem if you can assign one ip-number for each name, and the reason people can't always do that for http is that they have quite a large number of names for a single machine say (a web hosting service with with 100+ customers). > Now, it would be entirely possible to devise a new key exchange scheme, > which would carry the DNS name the client intends to connect to, in order > to allow the server host to select the corresponding private key and > certificate to respond with. However, it seems that it might be possible to > extend the current diffie-hellman-group1-sha1 in a backwards compatible > manner to include an optional string parameter in the DH_INIT packet: > > byte SSH_MSG_KEXDH_INIT > mpint e > string server dns name (optional) I prefer not adding complexity to security protocols. If one really wants to do this, one should also consider whether or not the name should be included in the definition exchange hash. There's also a client-side way to solve the problem: Have an option to the client that looks up a "canonical name" for the host (whatever that means: following CNAMES in DNS, or performing reverse-lookup on the ip-address of the target, or some such), and if it differs from the hostname as written by the user, the client will (i) display the canonical name to the user, and (ii) use that name when verifying certificates. /Niels PS. Your mail looked quite anonymous, with a from address of "ietf-ssh@clinet.fi" and no name or .signature. I can't say if that a clinet.fi mailing-list problem, a Lotus Notes problem, or a local oz.is configuration error? From owner-ietf-ssh@clinet.fi Wed Sep 6 12:50:24 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17477 for ; Wed, 6 Sep 2000 12:50:23 -0400 (EDT) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA16897 for ietf-ssh-outgoing; Wed, 6 Sep 2000 17:58:27 +0300 Received: from toto.oz.is (toto.oz.is [193.4.211.170]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA16889 for ; Wed, 6 Sep 2000 17:58:25 +0300 Received: from kansas.intranet.oz.is (scarecrow.oz.is [193.4.211.95]) by toto.oz.is (8.9.3/8.9.3) with ESMTP id PAA22649 for ; Wed, 6 Sep 2000 15:03:49 GMT Subject: Re: A comment on certificate-based server authentication and multiple DNS names To: ietf-ssh@clinet.fi X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000 Message-ID: Date: Wed, 6 Sep 2000 14:53:20 +0000 X-MIMETrack: Serialize by Router on OZ-ICE/OZ-Inc(Release 5.0.3 (Intl)|21 March 2000) at 06.09.2000 14:53:51 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ssh@clinet.fi Precedence: bulk nisse@lysator.liu.se wrote: >owner-ietf-ssh@clinet.fi writes: > >> There is however a problem when a single server host may respond to >> more than one DNS name. This problem is analogous to the one in >> initial versions of the HTTP protocol, which made it impossible to >> serve multiple domains from a single IP number. > >I don't see this as big problem; I don't think people usually do large >scale "virtual hosting" for ssh. There's no problem if you can assign >one ip-number for each name, and the reason people can't always do >that for http is that they have quite a large number of names for a >single machine say (a web hosting service with with 100+ customers). > I don't think you're giving the protocol the credit it deserves. SSH's utility is not limited to providing a secure login, the basic feature of connection multiplexing with end-to-end flow control is useful for many other applications. Even if you do limit the scope to secure login applications, the current specification would make it unduly difficult for IPP (Internet Presence Provider) VARs to provide a secure login to their virtual domains, especially since ARIN is clamping down on IP allocations for virtual hosting (see http://whois.arin.net/announcements/policy_changes.html). It also seems as though RIPE is allocating address ranges for virtual hosting only on the condition that they be returned once HTTP 1.1 is "widely deployed" (see http://www.ripe.net/ripencc/tips/http.html). >> Now, it would be entirely possible to devise a new key exchange scheme, >> which would carry the DNS name the client intends to connect to, in order >> to allow the server host to select the corresponding private key and >> certificate to respond with. However, it seems that it might be possible to >> extend the current diffie-hellman-group1-sha1 in a backwards compatible >> manner to include an optional string parameter in the DH_INIT packet: >> >> byte SSH_MSG_KEXDH_INIT >> mpint e >> string server dns name (optional) > >I prefer not adding complexity to security protocols. I agree, but the utility and the relatively low additional complexity of this addition justify it in my mind. >If one really >wants to do this, one should also consider whether or not the name >should be included in the definition exchange hash. > I don't think that should be necessary, since the only purpose of the DNS name parameter is to allow the server to select the correct private key to use for generating the exchange signature and the certificate to include in the DH response. The certificate will then provide a binding/reference to the DNS name (or some other attribute that identifies the destination). >There's also a client-side way to solve the problem: Have an option to >the client that looks up a "canonical name" for the host (whatever >that means: following CNAMES in DNS, or performing reverse-lookup on >the ip-address of the target, or some such), and if it differs from >the hostname as written by the user, the client will > > (i) display the canonical name to the user, and > (ii) use that name when verifying certificates. > This is assuming that there is a such a thing as a canonical name for the host. A common setup for virtual hosting is to have multiple A-records point to the same IP address, and the majority of reverse domains are misconfigured (see http://sc.menandmice.com/). This is also assuming that there's a user sitting at the originating end of the connection, again limiting the utility of the protocol for other applications than interactive, secure logon. >/Niels > >PS. Your mail looked quite anonymous, with a from address of >"ietf-ssh@clinet.fi" and no name or .signature. I can't say if that a >clinet.fi mailing-list problem, a Lotus Notes problem, or a local >oz.is configuration error? How quaint. I don't use a signature, but the from address should be correct. From owner-ietf-ssh@clinet.fi Wed Sep 6 14:24:08 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19959 for ; Wed, 6 Sep 2000 14:24:08 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA27360 for ietf-ssh-outgoing; Wed, 6 Sep 2000 19:33:47 +0300 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA27355 for ; Wed, 6 Sep 2000 19:33:44 +0300 Received: from sandelman.ottawa.on.ca (istari.sandelman.ottawa.on.ca [209.151.24.30]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id MAA07908 for ; Wed, 6 Sep 2000 12:33:42 -0400 (EDT) Received: from istari.sandelman.ottawa.on.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (8.8.8/8.7.3) with ESMTP id MAA01163 for ; Wed, 6 Sep 2000 12:33:41 -0400 (EDT) Message-Id: <200009061633.MAA01163@sandelman.ottawa.on.ca> To: ietf-ssh@clinet.fi Subject: Re: A comment on certificate-based server authentication and multiple DNS names In-Reply-To: Your message of "Wed, 06 Sep 2000 14:53:20 -0000." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 06 Sep 2000 12:33:41 -0400 From: Michael Richardson Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Current SSH 1.x has the problem: 1) it can not cope with load balanced machines. I.e. if I ssh to "smtp.example.com" and that has multiple A records, then I may get warnings when I log into a different box than last time. Unless, I synchronize the host keys, which I may not wish to do. 2) it can not cope with different port numbers. I use modified sshd on a different port number to access a custom chroot jail. 3) I may need to SSH to "www.example.com" to administrate the system. SSH is happy to permit multiple names to map to the same A record right now. If www.example.com moves to a different physical box, then I get warned (which is good). But, I don't have to guess which system it is currently on. So, people *do* do virtual hosting with SSH. They use it to administrate the systems on which they do virtual hosting. Further, consider use of SFTP for uploading of web content! Current SSH Oy SSH 2 implementations now record port numbers and stuff. They do not as I recall record name->IP mappings. This is implementation stuff. If there is something in the protocol that prevents a server from serving multiple mappings of name->IP addresses, then there is a problem. (I don't understand the problem though) :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ietf-ssh@clinet.fi Wed Sep 6 15:02:59 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20847 for ; Wed, 6 Sep 2000 15:02:59 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA29308 for ietf-ssh-outgoing; Wed, 6 Sep 2000 19:53:47 +0300 Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA29303 for ; Wed, 6 Sep 2000 19:53:45 +0300 Received: from mosquito.extremenetworks.com ([10.0.8.120]) by sol.extremenetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SKW7BTX2; Wed, 6 Sep 2000 09:52:54 -0700 Message-Id: <4.3.2.7.2.20000906124614.00ac5220@sol.extremenetworks.com> X-Sender: rja@sol.extremenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Sep 2000 12:48:32 -0400 To: ietf-ssh@clinet.fi From: RJ Atkinson Subject: Fwd: Re: A comment on certificate-based server authentication and multiple DNS names Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk >From: owner-ietf-ssh@clinet.fi >Subject: Re: A comment on certificate-based server authentication and multiple DNS > names >Keywords: >To: ietf-ssh@clinet.fi >X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000 >Date: Wed, 6 Sep 2000 14:53:20 +0000 >X-MIMETrack: Serialize by Router on OZ-ICE/OZ-Inc(Release 5.0.3 (Intl)|21 March 2000) at > 06.09.2000 14:53:51 >Sender: owner-ietf-ssh@clinet.fi > >Neils wrote: >>PS. Your mail looked quite anonymous, with a from address of >>"ietf-ssh@clinet.fi" and no name or .signature. I can't say if that a >>clinet.fi mailing-list problem, a Lotus Notes problem, or a local >>oz.is configuration error? Anonymous correspondent wrote: > How quaint. I don't use a signature, but the from address >should be correct. Not even. Full headers from your email are prepended to the top of this email. It looks like maybe a Lotus Notes bug or an MTA weirdness. Any road, a signature (formal or informal) would be helpful given what's happening to the headers. :-) Ran rja@inet.org From owner-ietf-ssh@clinet.fi Sun Sep 10 22:38:03 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13467 for ; Sun, 10 Sep 2000 22:38:01 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA19863 for ietf-ssh-outgoing; Mon, 11 Sep 2000 02:43:41 +0300 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA19858 for ; Mon, 11 Sep 2000 02:43:40 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 90CF6240A456 for ; Mon, 11 Sep 2000 01:43:29 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id BAA08541; Mon, 11 Sep 2000 01:43:29 +0200 (MET DST) To: ietf-ssh@clinet.fi Subject: New bulk encryption algorithms From: nisse@lysator.liu.se (Niels Möller) Date: 11 Sep 2000 01:43:29 +0200 Message-ID: Lines: 5 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I'm about to add support for serpent and rijndael to LSH. I'm using the names "rijndael-cbc" and "serpent-cbc". Both use 256 bit keys, and cbc chaining, just like for twofish. Comments? /Niels From owner-ietf-ssh@clinet.fi Mon Sep 11 01:26:13 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16969 for ; Mon, 11 Sep 2000 01:26:12 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id FAA30555 for ietf-ssh-outgoing; Mon, 11 Sep 2000 05:28:03 +0300 Received: from syrinx.oankali.net (syrinx.oankali.net [206.243.169.50]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id FAA30551 for ; Mon, 11 Sep 2000 05:28:01 +0300 Received: (from res@localhost) by syrinx.oankali.net (8.9.3/8.9.3) id WAA03239; Sun, 10 Sep 2000 22:24:55 -0400 Date: Sun, 10 Sep 2000 22:24:55 -0400 (EDT) From: "Richard E. Silverman" X-Sender: res@syrinx.oankali.net Reply-To: "Richard E. Silverman" To: SECSH Discussion List Subject: compression/encryption order Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk As far as I can tell, the transport draft does not actually say in what order encryption and compression should take place. Of course, it's normal practice to compress first, then encrypt -- and this is what all the implementations do -- but still it should be explicit. If I've missed it somehow, I'm sure my oversight will be promptly corrected. :) -- Richard Silverman slade@shore.net From owner-ietf-ssh@clinet.fi Mon Sep 11 07:29:12 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29084 for ; Mon, 11 Sep 2000 07:29:11 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA16808 for ietf-ssh-outgoing; Mon, 11 Sep 2000 11:05:49 +0300 Received: from smtp.clinet.fi (smtp.clinet.fi [194.100.0.12]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id LAA16777 for ; Mon, 11 Sep 2000 11:05:46 +0300 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by smtp.clinet.fi (8.9.3/8.9.3) with ESMTP id KAA94626 for ; Mon, 11 Sep 2000 10:57:53 +0300 (EEST) Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 6D7DF2408AC4; Mon, 11 Sep 2000 10:03:39 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id KAA13249; Mon, 11 Sep 2000 10:03:39 +0200 (MET DST) To: "Richard E. Silverman" Cc: SECSH Discussion List Subject: Re: compression/encryption order References: From: nisse@lysator.liu.se (Niels Möller) Date: 11 Sep 2000 10:03:38 +0200 In-Reply-To: "Richard E. Silverman"'s message of "Sun, 10 Sep 2000 22:24:55 -0400 (EDT)" Message-ID: Lines: 57 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk "Richard E. Silverman" writes: > As far as I can tell, the transport draft does not actually say in what > order encryption and compression should take place. Of course, it's > normal practice to compress first, then encrypt -- and this is what all > the implementations do -- but still it should be explicit. I think the transport draft does specify the correct order, although it might be a good idea to make that more explicit. More precisely, the current draft says: : 4. Binary Packet Protocol : : Each packet is of the following format. : : uint32 packet_length : byte padding_length : byte[n1] payload; n1 = packet_length - padding_length - 1 : : byte[n2] random padding; n2 = padding_length : byte[m] mac (message authentication code); m = mac_length : : packet_length : The length of the packet (bytes), not including MAC or the : packet_length field itself. : : padding_length : Length of padding (bytes). : : payload :! The useful contents of the packet. If compression has been :! negotiated, this field is compressed. Initially, compression MUST :! be "none". : : Padding : Arbitrary-length padding, such that the total length of : (packet_length || padding_length || payload || padding) is a : multiple of the cipher block size or 8, whichever is larger. : There MUST be at least four bytes of padding. The padding SHOULD : consist of random bytes. The maximum amount of padding is 255 : bytes. : : MAC : Message authentication code. If message authentication has been : negotiated, this field contains the MAC bytes. Initially, the MAC : algorithm MUST be "none". ... : 4.3. Encryption : : An encryption algorithm and a key will be negotiated during the key : exchange. When encryption is in effect, the packet length, padding :!length, payload and padding fields of each packet MUST be encrypted with : the given algorithm. /Niels From owner-ietf-ssh@clinet.fi Mon Sep 11 07:29:42 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29115 for ; Mon, 11 Sep 2000 07:29:41 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA23155 for ietf-ssh-outgoing; Mon, 11 Sep 2000 11:27:28 +0300 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id LAA23124 for ; Mon, 11 Sep 2000 11:27:18 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id A44FD240A013; Mon, 11 Sep 2000 10:27:17 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id KAA13459; Mon, 11 Sep 2000 10:27:17 +0200 (MET DST) To: Michael Richardson Cc: ietf-ssh@clinet.fi Subject: Re: A comment on certificate-based server authentication and multiple DNS names References: <200009061633.MAA01163@sandelman.ottawa.on.ca> From: nisse@lysator.liu.se (Niels Möller) Date: 11 Sep 2000 10:27:17 +0200 In-Reply-To: Michael Richardson's message of "Wed, 06 Sep 2000 12:33:41 -0400" Message-ID: Lines: 58 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Appearantly, there are some more issues here than I was aware of when I wrote my previous article on the subject... Michael Richardson writes: > Current SSH 1.x has the problem: > 1) it can not cope with load balanced machines. I.e. if I > ssh to "smtp.example.com" and that has multiple A records, then > I may get warnings when I log into a different box than last time. > Unless, I synchronize the host keys, which I may not wish to do. If the clients are to be unaware that smtp.example.com is actually several distinct machines, they will get confused if they randomly get different hostkeys when connecting to that. The current ssh practice and implementations more or less requires "One machine, one host key". Perhaps one could record several keys in the known_hosts database. (Another solution is to have a master key for the "virtual machine" smtp.example.com, and use that key to create certificates for the individual machines. But that will probably not work and interoperate in practice for some time to come). > 2) it can not cope with different port numbers. I use modified > sshd on a different port number to access a custom chroot jail. That's a bug, I would say. If it's fixed in SSH Oy SSH2 (as you say below), that's good. > Current SSH Oy SSH 2 implementations now record port numbers and stuff. > They do not as I recall record name->IP mappings. This is implementation > stuff. It's probably a bad idea to record ip-numbers. > If there is something in the protocol that prevents a server from serving > multiple mappings of name->IP addresses, then there is a problem. (I don't > understand the problem though) As I understand it, the problem occurs if: 1. A server hosts both foo.example.com and bar.example.com, using the same ip-number and port. 2. One wants to use distinct host keys for the two names, say FOOKEY and BARKEY. When a client connects, the server has to choose to use one of the keys to prove its autenticity. If the client believes it is connecting to "bar.example.com", the server has to use BARKEY, else FOOKEY. However, the server doesn't have enough information to make the right choice. The suggestion is to add somthing similar to the http host:-header to some early keyexchange packet. I'm not yet conviced that is a good idea. /Niels From owner-ietf-ssh@clinet.fi Mon Sep 11 07:39:12 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29368 for ; Mon, 11 Sep 2000 07:39:11 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA25934 for ietf-ssh-outgoing; Mon, 11 Sep 2000 11:37:46 +0300 Received: from syrinx.oankali.net (syrinx.oankali.net [206.243.169.50]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id LAA25896 for ; Mon, 11 Sep 2000 11:37:36 +0300 Received: (from res@localhost) by syrinx.oankali.net (8.9.3/8.9.3) id EAA05275; Mon, 11 Sep 2000 04:34:48 -0400 Date: Mon, 11 Sep 2000 04:34:48 -0400 (EDT) From: "Richard E. Silverman" X-Sender: res@syrinx.oankali.net Reply-To: "Richard E. Silverman" To: SECSH Discussion List Subject: Re: compression/encryption order In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.clinet.fi id LAA25901 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id LAA25934 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA29368 On 11 Sep 2000, Niels Möller wrote: > I think the transport draft does specify the correct order, although > it might be a good idea to make that more explicit. More precisely, > the current draft says: ... I noticed this when reading it, but I find it ambiguous. In one way of reading, it does imply an order: "payload" is defined as compressed if compression is on, and encryption is defined as operating on the payload. However, the title of the section is "Binary Packet Protocol;" it describes the format of a packet in general -- and it does not say whether it is describing it before or after encryption. A packet after encryption is just as much a "packet" as one before, so in that sense it's not clear whether the direction to compress the payload "if compression has been negotiated" applies to the payload before or after encryption. -- Richard Silverman slade@shore.net From owner-ietf-ssh@clinet.fi Mon Sep 11 12:09:38 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05771 for ; Mon, 11 Sep 2000 12:09:37 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA27659 for ietf-ssh-outgoing; Mon, 11 Sep 2000 16:01:48 +0300 Received: from alcove.wittsend.com (IDENT:root@alcove.wittsend.com [130.205.0.20]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA27642 for ; Mon, 11 Sep 2000 16:01:43 +0300 Received: (from mhw@localhost) by alcove.wittsend.com (8.9.3/8.9.3) id JAA12876; Mon, 11 Sep 2000 09:01:39 -0400 Date: Mon, 11 Sep 2000 09:01:39 -0400 From: "Michael H. Warfield" To: "Richard E. Silverman" Cc: SECSH Discussion List Subject: Re: compression/encryption order Message-ID: <20000911090139.A5963@alcove.wittsend.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.2i In-Reply-To: ; from res@shore.net on Sun, Sep 10, 2000 at 10:24:55PM -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Sun, Sep 10, 2000 at 10:24:55PM -0400, Richard E. Silverman wrote: > As far as I can tell, the transport draft does not actually say in what > order encryption and compression should take place. Of course, it's > normal practice to compress first, then encrypt -- and this is what all > the implementations do -- but still it should be explicit. If you think about it, compression before encryption is the only one that really makes sense. If you encrypted it first, the compression would be unable to do much. Ideally, the encryption should result in data that looks very similar to noise and not very compressible. Making it "explicit" may be something on the order of making the obvious more apparent. > If I've missed it somehow, I'm sure my oversight will be promptly > corrected. :) > -- > Richard Silverman > slade@shore.net -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ietf-ssh@clinet.fi Mon Sep 11 14:36:17 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07693 for ; Mon, 11 Sep 2000 14:36:17 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA22876 for ietf-ssh-outgoing; Mon, 11 Sep 2000 18:55:32 +0300 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA22870 for ; Mon, 11 Sep 2000 18:55:30 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id CAE9E24016FA; Mon, 11 Sep 2000 17:55:29 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id RAA18212; Mon, 11 Sep 2000 17:55:29 +0200 (MET DST) To: Tero Kivinen Cc: ietf-ssh@clinet.fi Subject: Re: New bulk encryption algorithms References: <14780.63878.223481.692092@hutcs.cs.hut.fi> From: nisse@lysator.liu.se (Niels Möller) Date: 11 Sep 2000 17:55:29 +0200 In-Reply-To: Tero Kivinen's message of "Mon, 11 Sep 2000 18:40:02 +0300 (EET DST)" Message-ID: Lines: 26 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tero Kivinen writes: > Niels Möller writes: > > I'm about to add support for serpent and rijndael to LSH. I'm using > > the names "rijndael-cbc" and "serpent-cbc". Both use 256 bit keys, and > > cbc chaining, just like for twofish. Comments? > > I think that is good idea, but use rijndael-cbc@lysator.liu.se > and serpent-cbc@lysator.liu.se instead as long as there is no draft > out and those names has not yet been allocated from IANA. Allocating > those names from IANA can be little hard now, because the base draft > is not yet out as an RFC. Ok, I'll do that (the same applies to my SRP support, I guess). > I think the most important thing to do not is to get the RFC out, and > I would really like people to concentrate on that, and postpone all > new ideas etc after that. I can understand that point of view, but I also spend some time hacking on my implementation. I think it is a good thing to have the wg informed about what implementors do, even if standardizing those things is not urgent. /Niels . From owner-ietf-ssh@clinet.fi Mon Sep 11 14:38:33 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07724 for ; Mon, 11 Sep 2000 14:38:33 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA21631 for ietf-ssh-outgoing; Mon, 11 Sep 2000 18:45:32 +0300 Received: from star.inter.net.il (star.inter.net.il [192.116.202.84]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA21624 for ; Mon, 11 Sep 2000 18:45:30 +0300 Received: from localhost.localdomain ([213.8.217.209]) by star.inter.net.il (8.10.1/8.10.1) with ESMTP id e8BFij111928 for ; Mon, 11 Sep 2000 18:44:45 +0300 (IDT) Received: from localhost (baruch@localhost) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id SAA01011 for ; Mon, 11 Sep 2000 18:46:50 +0200 Date: Mon, 11 Sep 2000 18:46:48 +0200 (IST) From: Baruch Even To: SECSH Discussion List Subject: Re: compression/encryption order In-Reply-To: <20000911090139.A5963@alcove.wittsend.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Mon, 11 Sep 2000, Michael H. Warfield wrote: > On Sun, Sep 10, 2000 at 10:24:55PM -0400, Richard E. Silverman wrote: > > > As far as I can tell, the transport draft does not actually say in what > > order encryption and compression should take place. Of course, it's > > normal practice to compress first, then encrypt -- and this is what all > > the implementations do -- but still it should be explicit. > > If you think about it, compression before encryption is the only > one that really makes sense. If you encrypted it first, the compression > would be unable to do much. Ideally, the encryption should result in > data that looks very similar to noise and not very compressible. Making > it "explicit" may be something on the order of making the obvious more > apparent. It is true, but I think that for completeness sake it should be stated explicitly, there might be a need for a programmer not well versed in cryptography to implement the algorithms and such a fact is better stated explicitly then left to the unwary to worry about. Baruch From owner-ietf-ssh@clinet.fi Mon Sep 11 15:04:23 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08107 for ; Mon, 11 Sep 2000 15:04:22 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA25768 for ietf-ssh-outgoing; Mon, 11 Sep 2000 19:17:25 +0300 Received: from syrinx.oankali.net (syrinx.oankali.net [206.243.169.50]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA25759 for ; Mon, 11 Sep 2000 19:17:23 +0300 Received: (from res@localhost) by syrinx.oankali.net (8.9.3/8.9.3) id MAA05582; Mon, 11 Sep 2000 12:14:35 -0400 Date: Mon, 11 Sep 2000 12:14:35 -0400 (EDT) From: "Richard E. Silverman" X-Sender: res@syrinx.oankali.net Reply-To: "Richard E. Silverman" To: SECSH Discussion List Subject: Re: compression/encryption order In-Reply-To: <20000911090139.A5963@alcove.wittsend.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Michael and Mika have opined that there's no need to make the compression/encryption order more explicit in the draft, because it's obvious and common knowledge. I'm aware of the reasons for doing it this way; that's why I wrote: res> Of course, it's normal practice to compress first, then encrypt ... Obviously, I should have been more explicit about what I meant. :) Anyway, I disagree strongly with this point of view. Something being obvious is not a reason to leave it out of a specification, or to leave it obscure or unclear. *Everything* in a specification should be explicit; that's why it's a specification and not a poem. Opinions on "obviousness" vary widely, and any ambiguity is an opportunity for future incompatibility among implementations, perhaps in a context we can't think of now in which the point is not so clear. Belaboring the obvious is a small price to pay for avoiding that. -- Richard Silverman slade@shore.net From owner-ietf-ssh@clinet.fi Mon Sep 11 15:36:48 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08447 for ; Mon, 11 Sep 2000 15:36:47 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA29279 for ietf-ssh-outgoing; Mon, 11 Sep 2000 19:46:51 +0300 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA29276 for ; Mon, 11 Sep 2000 19:46:48 +0300 Received: from sandelman.ottawa.on.ca (istari.sandelman.ottawa.on.ca [209.151.24.30]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id MAA14829 for ; Mon, 11 Sep 2000 12:46:46 -0400 (EDT) Received: from istari.sandelman.ottawa.on.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (8.8.8/8.7.3) with ESMTP id MAA11621 for ; Mon, 11 Sep 2000 12:46:44 -0400 (EDT) Message-Id: <200009111646.MAA11621@sandelman.ottawa.on.ca> To: ietf-ssh@clinet.fi Subject: Re: A comment on certificate-based server authentication and multiple DNS names In-Reply-To: Your message of "11 Sep 2000 10:27:17 +0200." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 11 Sep 2000 12:46:44 -0400 From: Michael Richardson X-MIME-Autoconverted: from quoted-printable to 8bit by mail.clinet.fi id TAA29277 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id TAA29279 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA08447 >>>>> "Niels" == Niels Möller writes: Niels> If the clients are to be unaware that smtp.example.com is actually Niels> several distinct machines, they will get confused if they randomly get Niels> different hostkeys when connecting to that. The current ssh practice Niels> and implementations more or less requires "One machine, one host key". Niels> Perhaps one could record several keys in the known_hosts database. Niels> (Another solution is to have a master key for the "virtual machine" Niels> smtp.example.com, and use that key to create certificates for the Niels> individual machines. But that will probably not work and interoperate Niels> in practice for some time to come). The index can be: name, IP-address, port => host-key Yes, it would be good to have such a certificate eventually. In another revision of the spec. >> 2) it can not cope with different port numbers. I use modified >> sshd on a different port number to access a custom chroot jail. Niels> That's a bug, I would say. If it's fixed in SSH Oy SSH2 (as you say Niels> below), that's good. Yes, it is mostly. I just wanted to remind that this use. >> Current SSH Oy SSH 2 implementations now record port numbers and stuff. >> They do not as I recall record name->IP mappings. This is implementation >> stuff. Niels> It's probably a bad idea to record ip-numbers. I disagree. I care if the name->IP mapping chanes as much as I change that the host key changes. In fact, the host key may have changed because the name->IP mapping changed. Niels> As I understand it, the problem occurs if: Niels> 1. A server hosts both foo.example.com and bar.example.com, using the Niels> same ip-number and port. Niels> 2. One wants to use distinct host keys for the two names, say FOOKEY Niels> and BARKEY. Niels> When a client connects, the server has to choose to use one of the Niels> keys to prove its autenticity. If the client believes it is connecting Niels> to "bar.example.com", the server has to use BARKEY, else FOOKEY. Niels> However, the server doesn't have enough information to make the right Niels> choice. Niels> The suggestion is to add somthing similar to the http host:-header to Niels> some early keyexchange packet. I'm not yet conviced that is a good Niels> idea. I see. I do not support the idea of multiple host keys per host. HTTPS has the same problem, btw. My solution above of name,IP-address -> key solves this problem. :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ietf-ssh@clinet.fi Mon Sep 11 16:08:47 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08665 for ; Mon, 11 Sep 2000 16:08:46 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA32624 for ietf-ssh-outgoing; Mon, 11 Sep 2000 20:16:07 +0300 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA32618 for ; Mon, 11 Sep 2000 20:16:05 +0300 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29060 for ; Mon, 11 Sep 2000 10:16:02 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA07990 for ; Mon, 11 Sep 2000 13:11:39 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e8BHB9G114756 for ; Mon, 11 Sep 2000 13:11:09 -0400 (EDT) Message-Id: <200009111711.e8BHB9G114756@thunk.east.sun.com> From: Bill Sommerfeld To: SECSH Discussion List Subject: Re: compression/encryption order In-reply-to: Your message of "Mon, 11 Sep 2000 12:14:35 EDT." Reply-to: sommerfeld@east.sun.com Date: Mon, 11 Sep 2000 13:11:09 -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Since the draft is due for a revision anyway, sounds like it should be clarified to say "compress, then encrypt". Any strong objections? - Bill From owner-ietf-ssh@clinet.fi Mon Sep 11 17:28:48 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09222 for ; Mon, 11 Sep 2000 17:28:47 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA08569 for ietf-ssh-outgoing; Mon, 11 Sep 2000 21:35:54 +0300 Received: from alcove.wittsend.com (IDENT:root@alcove.wittsend.com [130.205.0.20]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id VAA08562 for ; Mon, 11 Sep 2000 21:35:53 +0300 Received: (from mhw@localhost) by alcove.wittsend.com (8.9.3/8.9.3) id OAA20186; Mon, 11 Sep 2000 14:35:48 -0400 Date: Mon, 11 Sep 2000 14:35:47 -0400 From: "Michael H. Warfield" To: "Richard E. Silverman" Cc: SECSH Discussion List Subject: Re: compression/encryption order Message-ID: <20000911143547.A19571@alcove.wittsend.com> References: <20000911090139.A5963@alcove.wittsend.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.2i In-Reply-To: ; from res@shore.net on Mon, Sep 11, 2000 at 12:14:35PM -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Mon, Sep 11, 2000 at 12:14:35PM -0400, Richard E. Silverman wrote: [...] > Anyway, I disagree strongly with this point of view. Something being > obvious is not a reason to leave it out of a specification, or to leave it > obscure or unclear. *Everything* in a specification should be explicit; > that's why it's a specification and not a poem. Opinions on "obviousness" > vary widely, and any ambiguity is an opportunity for future > incompatibility among implementations, perhaps in a context we can't think > of now in which the point is not so clear. Belaboring the obvious is a > small price to pay for avoiding that. I'm fine with that as long as... 1) We recognize that we are belaboring the obvious. 2) We do not go so overboard in belaboring the obvious that the standard becomes unreadable. I agree that abiguity is bad and should be avoided at all cost. > -- > Richard Silverman > slade@shore.net Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ietf-ssh@clinet.fi Tue Sep 12 07:59:28 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00762 for ; Tue, 12 Sep 2000 07:59:27 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA22197 for ietf-ssh-outgoing; Tue, 12 Sep 2000 11:57:36 +0300 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id LAA22173 for ; Tue, 12 Sep 2000 11:57:32 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id ADB4D24016E2; Tue, 12 Sep 2000 10:57:31 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id KAA27951; Tue, 12 Sep 2000 10:57:31 +0200 (MET DST) To: Michael Richardson Cc: ietf-ssh@clinet.fi Subject: Re: A comment on certificate-based server authentication and multiple DNS names References: <200009111646.MAA11621@sandelman.ottawa.on.ca> From: nisse@lysator.liu.se (Niels Möller) Date: 12 Sep 2000 10:57:31 +0200 In-Reply-To: Michael Richardson's message of "Mon, 11 Sep 2000 12:46:44 -0400" Message-ID: Lines: 33 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Michael Richardson writes: > The index can be: > name, IP-address, port => host-key ... > I do not support the idea of multiple host keys per host. > HTTPS has the same problem, btw. > > My solution above of name,IP-address -> key solves this problem. I believe you solve a different problem. There are a few different cases: 1. Single/multiple names, single ip, single hostkey (default operation, no problem) 2. Multiple names, multiple ip, multiple hostkeys. This flavour of "virtual hosting" should also be no problem, just have one ssh daemon listening on each ip. If we compare to https, in this case it works with no problem. 3. Multiple names, single ip, multiple hostkeys. This is where a host-header-equivalent would help, while recording ip-numbers is useless. This is exactly the same problem as with https "ip-less virtual hosting". 4. Single name, multiple ip, multiple hostkeys. This is the load-balancing case. Recording ip-numbers would help here. /Niels From owner-ietf-ssh@clinet.fi Tue Sep 12 16:50:26 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14127 for ; Tue, 12 Sep 2000 16:50:25 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA20521 for ietf-ssh-outgoing; Tue, 12 Sep 2000 20:36:44 +0300 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA20514 for ; Tue, 12 Sep 2000 20:36:43 +0300 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA25517; Tue, 12 Sep 2000 10:36:34 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA08327; Tue, 12 Sep 2000 13:36:33 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e8CHa4f100872; Tue, 12 Sep 2000 13:36:04 -0400 (EDT) Message-Id: <200009121736.e8CHa4f100872@thunk.east.sun.com> From: Bill Sommerfeld To: nisse@lysator.liu.se (Niels M ller) cc: Michael Richardson , ietf-ssh@clinet.fi Subject: Re: A comment on certificate-based server authentication and multiple DNS names In-reply-to: Your message of "12 Sep 2000 10:57:31 +0200." Reply-to: sommerfeld@east.sun.com Date: Tue, 12 Sep 2000 13:36:04 -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk [wg chair hat off] Certificates bind a name to a key; they don't just say "this is an ssh host key", they say, "this is lysator.liu.se's ssh host key". The client, when verifying a server's certificate, needs to make sure that the name supplied by the end-user and the/a name in the server's certificate match.. 1. Single/multiple names, single ip, single hostkey (default operation, no problem) If we add certificates to the mix, we need to split this case: 1a. single name, single ip, single hostkey, single cert. 1b. multiple names, single ip, single hostkey, multiple names in certificate. 1c. multiple names, single ip, single hostkey, multiple certificates. - Bill From owner-ietf-ssh@clinet.fi Tue Sep 12 18:48:07 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14931 for ; Tue, 12 Sep 2000 18:48:06 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA31979 for ietf-ssh-outgoing; Tue, 12 Sep 2000 22:56:22 +0300 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA31841 for ; Tue, 12 Sep 2000 22:56:07 +0300 Received: from sandelman.ottawa.on.ca (istari.sandelman.ottawa.on.ca [209.151.24.30]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id PAA04828 for ; Tue, 12 Sep 2000 15:56:05 -0400 (EDT) Received: from istari.sandelman.ottawa.on.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (8.8.8/8.7.3) with ESMTP id PAA14022 for ; Tue, 12 Sep 2000 15:56:02 -0400 (EDT) Message-Id: <200009121956.PAA14022@sandelman.ottawa.on.ca> To: ietf-ssh@clinet.fi Subject: Re: A comment on certificate-based server authentication and multiple DNS names In-Reply-To: Your message of "12 Sep 2000 10:57:31 +0200." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 12 Sep 2000 15:56:02 -0400 From: Michael Richardson X-MIME-Autoconverted: from quoted-printable to 8bit by mail.clinet.fi id WAA31976 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id WAA31979 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA14931 >>>>> "Niels" == Niels Möller writes: Niels> I believe you solve a different problem. There are a few different Niels> cases: Good description. Niels> 1. Single/multiple names, single ip, single hostkey (default Niels> operation, no problem) Niels> 2. Multiple names, multiple ip, multiple hostkeys. This flavour of Niels> "virtual hosting" should also be no problem, just have one ssh Niels> daemon listening on each ip. If we compare to https, in this case Niels> it works with no problem. Niels> 3. Multiple names, single ip, multiple hostkeys. This is where a Niels> host-header-equivalent would help, while recording ip-numbers is Niels> useless. This is exactly the same problem as with https "ip-less Niels> virtual hosting". Niels> 4. Single name, multiple ip, multiple hostkeys. This is the Niels> load-balancing case. Recording ip-numbers would help here. I suggest that having multiple host keys is not that important. HTTPS has a big problem with #3 because they can not present multiple names with the same certificate. As SecSH does not yet deal in certificates, I suggest that the problem should be solved at that point. :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ietf-ssh@clinet.fi Tue Sep 12 19:39:38 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15275 for ; Tue, 12 Sep 2000 19:39:37 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA03467 for ietf-ssh-outgoing; Tue, 12 Sep 2000 23:46:14 +0300 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA03463 for ; Tue, 12 Sep 2000 23:46:13 +0300 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA15782; Tue, 12 Sep 2000 13:46:07 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA21230; Tue, 12 Sep 2000 16:46:02 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e8CKjWf101325; Tue, 12 Sep 2000 16:45:32 -0400 (EDT) Message-Id: <200009122045.e8CKjWf101325@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Richardson cc: ietf-ssh@clinet.fi Subject: Re: A comment on certificate-based server authentication and multiple DNS names In-reply-to: Your message of "Tue, 12 Sep 2000 15:56:02 EDT." <200009121956.PAA14022@sandelman.ottawa.on.ca> Reply-to: sommerfeld@east.sun.com Date: Tue, 12 Sep 2000 16:45:32 -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > HTTPS has a big problem with #3 because they can not present multiple > names with the same certificate. As SecSH does not yet deal in certificates, > I suggest that the problem should be solved at that point. There is "insert certificate here" text in the current set of drafts. - Bill From owner-ietf-ssh@clinet.fi Wed Sep 13 00:45:18 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19358 for ; Wed, 13 Sep 2000 00:45:17 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id FAA24192 for ietf-ssh-outgoing; Wed, 13 Sep 2000 05:02:52 +0300 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id FAA24172 for ; Wed, 13 Sep 2000 05:02:50 +0300 Received: from viper2 ([127.0.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 568 for ; Tue, 12 Sep 2000 20:03:00 -0600 Message-ID: <002901c01d27$2a94f8b0$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: References: <200009012350.e81NoJT108944@thunk.east.sun.com> Subject: Re: minutes from the SECSH working group meeting at the 48th IETF Date: Tue, 12 Sep 2000 20:05:57 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > File transfer > > Current sftp draft is not in any state. sftp protocol needs to be > documented, reviewed by the working group. file listing format should > take a look at what the FTP WG did for directory listings. I'd very much like to see some progress on getting sftp documented. At the Pittsburg meeting, I believe the understanding was that SSH Communications was going to prepare a draft. Is there a time frame for this? Is there anything that others can do to help with this effort? Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Wed Sep 13 09:59:06 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08403 for ; Wed, 13 Sep 2000 09:59:05 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id NAA04975 for ietf-ssh-outgoing; Wed, 13 Sep 2000 13:35:01 +0300 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id NAA04920 for ; Wed, 13 Sep 2000 13:34:46 +0300 Received: from zed.isi.edu (root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA22096; Wed, 13 Sep 2000 03:34:43 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.9.3/8.8.6) id DAA28515; Wed, 13 Sep 2000 03:34:43 -0700 Message-Id: <200009131034.DAA28515@zed.isi.edu> Subject: Re: A comment on certificate-based server authentication and multiple DNS names To: sommerfeld@east.sun.com Date: Wed, 13 Sep 2000 03:34:41 -0700 (PDT) Cc: nisse@lysator.liu.se (Niels M ller), mcr@sandelman.ottawa.on.ca (Michael Richardson), ietf-ssh@clinet.fi In-Reply-To: <200009121736.e8CHa4f100872@thunk.east.sun.com> from "Bill Sommerfeld" at Sep 12, 2000 01:36:04 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit % The client, when verifying a server's certificate, needs to make sure % that the name supplied by the end-user and the/a name in the server's % certificate match.. % % 1. Single/multiple names, single ip, single hostkey (default % operation, no problem) % % If we add certificates to the mix, we need to split this case: % % 1a. single name, single ip, single hostkey, single cert. % % 1b. multiple names, single ip, single hostkey, multiple names in certificate. % % 1c. multiple names, single ip, single hostkey, multiple certificates. % % - Bill 1d. single name, multiple ip, .... :) -- --bill From owner-ietf-ssh@clinet.fi Wed Sep 13 10:10:46 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08800 for ; Wed, 13 Sep 2000 10:10:45 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA11007 for ietf-ssh-outgoing; Wed, 13 Sep 2000 14:01:58 +0300 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id OAA10995 for ; Wed, 13 Sep 2000 14:01:55 +0300 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id NAA01252; Wed, 13 Sep 2000 13:01:49 +0200 (MET DST) Date: Wed, 13 Sep 2000 13:01:49 +0200 From: Markus Friedl To: "Jeff P. Van Dyke" Cc: ietf-ssh@clinet.fi Subject: Re: minutes from the SECSH working group meeting at the 48th IETF Message-ID: <20000913130149.A1228@faui02.informatik.uni-erlangen.de> References: <200009012350.e81NoJT108944@thunk.east.sun.com> <002901c01d27$2a94f8b0$0201a8c0@vandyke.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="IJpNTDwzlM2Ie8A6" In-Reply-To: <002901c01d27$2a94f8b0$0201a8c0@vandyke.com>; from jpv@vandyke.com on Tue, Sep 12, 2000 at 08:05:57PM -0600 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii On Tue, Sep 12, 2000 at 08:05:57PM -0600, Jeff P. Van Dyke wrote: > > File transfer > > > > Current sftp draft is not in any state. sftp protocol needs to be > > documented, reviewed by the working group. file listing format should > > take a look at what the FTP WG did for directory listings. > > I'd very much like to see some progress on getting sftp documented. here are my notes on the SFTP protocol. -m --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=SFTP // message types enum msgtypes { // init INIT = 1, VERSION = 2, // client requests OPEN = 3, CLOSE = 4, READ = 5, WRITE = 6, LSTAT = 7, FSTAT = 8, SETSTAT = 9, FSETSTAT = 10, OPENDIR = 11, READDIR = 12, REMOVE = 13, MKDIR = 14, RMDIR = 15, REALPATH = 16, STAT = 17, RENAME = 18, // server replies STATUS = 101, HANDLE = 102, DATA = 103, NAME = 104, ATTRS = 105 }; enum openflag { OPENFLAG_READ = 0x01, OPENFLAG_WRITE = 0x02, OPENFLAG_APPEND = 0x04, OPENFLAG_CREAT = 0x08, OPENFLAG_TRUNC = 0x10, OPENFLAG_EXCL = 0x20 }; enum attribflags { ATTRIB_HAVE_SIZE = 0x01, ATTRIB_HAVE_UGID = 0x02, ATTRIB_HAVE_PERM = 0x04, ATTRIB_HAVE_TIME = 0x08 }; // a 'string handle' is a reference to a open file or directory // the handle is chosen by the server and opaque to the client. // note that the server is statefull. // almost every message contains a 'id'. the 'uint32 id' is chosen // by the client and is used to find matching replies from the server // a sever just copies the id field into the reply // packets are encoded similar to the secsh transport layer with a // uint32 msglen // byte[1] msgtype // as defined above // byte[msglen-1] payload // e.g. the payload for a CLOSE message conists of // uint32 id // string handle // file attibutes are represented this way. note that // the presence of some fields depends on the value // of the 1st int 'flags' Attrib { uint32 flags; // see attribflags, above uint32 sizehigh; // if flags & ATTRIB_HAVE_SIZE uint32 sizelow; // if flags & ATTRIB_HAVE_SIZE uint32 uid; // if flags & ATTRIB_HAVE_UGID uint32 gid; // if flags & ATTRIB_HAVE_UGID uint32 perm; // if flags & ATTRIB_HAVE_PERM uint32 atime; // if flags & ATTRIB_HAVE_TIME uint32 mtime; // if flags & ATTRIB_HAVE_TIME } // client requests (and types for server replies) c->s: INIT (uint32 version) s->c: VERSION (uint32 version) c->s: OPEN (uint32 id, string name, uint32 openmode, Attrib a) // see openflag, above s->c: HANDLE or STATUS on failure // payload is defined below c->s: OPENDIR (uint32 id, string name) s->c: HANDLE or STATUS on failure c->s: CLOSE (uint32 id, string handle) // handle points to open dir/file s->c: STATUS c->s: READ (uint32 id, string handle, uint32 offhigh, unint32 offlow, uint32 len) s->c: DATA or STATUS on failure c->s: WRITE (uint32 id, string handle, uint32 offhigh, unint32 offlow, string data) s->c: DATA or STATUS on failure c->s: READDIR (uint32 id, string handle) s->c: NAMES or STATUS on failure c->s: STAT (uint32 id, string name) s->c: ATTRIB or STATUS on failure c->s: LSTAT (uint32 id, string name) s->c: ATTRIB or STATUS on failure c->s: FSTAT (uint32 id, string handle) s->c: ATTRIB or STATUS on failure c->s: SETSTAT (uint32 id, string name, Attrib a) s->c: STATUS c->s: FSETSTAT (uint32 id, string handle, Attrib a) s->c: STATUS c->s: REMOVE (uint32 id, string name) s->c: STATUS c->s: RMDIR (uint32 id, string name) s->c: STATUS c->s: MKDIR (uint32 id, string name, Attrib a) s->c: STATUS c->s: REALPATH (uint32 id, string name) s->c: NAMES or STATUS on failure c->s: RENAME (uint32 id, string old, string new) s->c: STATUS // server replies: s->c: STATUS (uint32 id, uint32 error) // id matches the request-id from client s->c: HANDLE (uint32 id, string name) s->c: DATA (uint32 id, string data) s->c: ATTRIB (uint32 id, Attrib a) s->c: NAMES (uint32 id, uint32 count, {string name, string longname, Attrib a}*count times) EOF --IJpNTDwzlM2Ie8A6-- From owner-ietf-ssh@clinet.fi Fri Sep 22 02:48:40 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03371 for ; Fri, 22 Sep 2000 02:48:39 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id HAA28135 for ietf-ssh-outgoing; Fri, 22 Sep 2000 07:36:21 +0300 Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id HAA28126 for ; Fri, 22 Sep 2000 07:36:19 +0300 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id VAA19927 for ; Thu, 21 Sep 2000 21:36:15 -0700 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id VAA22422 for ietf-ssh@clinet.fi; Thu, 21 Sep 2000 21:36:14 -0700 (PDT) Date: Thu, 21 Sep 2000 21:36:14 -0700 From: Wei Dai To: ietf-ssh@clinet.fi Subject: meaning of partial flush Message-ID: <20000921213614.E17038@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > The "zlib" compression is described in [RFC-1950] and in [RFC-1951]. The > compression context is initialized after each key exchange, and is > passed from one packet to the next with only a partial flush being > performed at the end of each packet. A partial flush means that all data > will be output, but the next packet will continue using compression > tables from the end of the previous packet. I was unable to find the exact definition of "partial flush" documented in either RFC 1950 or RFC 1951. After reading the ZLIB source code for half a day, I finally figured out that it means ending the current deflate block and adding one or two empty deflate blocks in order to finish up the current byte in the compression stream. While looking at the ZLIB source code, I also found this comment: #define Z_PARTIAL_FLUSH 1 /* will be removed, use Z_SYNC_FLUSH instead */ #define Z_SYNC_FLUSH 2 The difference between sync flush and partial flush is that sync flush would add an empty "store" block instead of the one or two empty deflate blocks. The store block causes the next deflate block to start at a byte boundary, but it uses up 4 more bytes than the empty deflate blocks. I think the meaning of "partial flush" should be clarified in the SSH standard, and also maybe we should consider using sync flush instead, since partial flush seems to be deprecated by the ZLIB authors. Another compression-related issue whether when a new compression stream starts (via SSH_MSG_NEWKEYS), the previous compression stream needs to end normally (which for ZLIB involves appending an ADLER32 checksum), or whether it can just terminate in the middle of the stream. From owner-ietf-ssh@clinet.fi Fri Sep 22 08:52:40 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12916 for ; Fri, 22 Sep 2000 08:52:39 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id NAA16173 for ietf-ssh-outgoing; Fri, 22 Sep 2000 13:49:41 +0300 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id NAA16078 for ; Fri, 22 Sep 2000 13:49:22 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id CB91424016E1; Fri, 22 Sep 2000 12:49:21 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id MAA22577; Fri, 22 Sep 2000 12:49:21 +0200 (MET DST) To: Wei Dai Cc: ietf-ssh@clinet.fi Subject: Re: meaning of partial flush References: <20000921213614.E17038@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Möller) Date: 22 Sep 2000 12:49:21 +0200 In-Reply-To: Wei Dai's message of "Thu, 21 Sep 2000 21:36:14 -0700" Message-ID: Lines: 44 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Wei Dai writes: > I was unable to find the exact definition of "partial flush" > documented in either RFC 1950 or RFC 1951. After reading the ZLIB source > code for half a day, I finally figured out that it means ending the > current deflate block and adding one or two empty deflate blocks in order > to finish up the current byte in the compression stream. I agree that it would be a good thing to make the spec clearer on this point. > While looking at the ZLIB source code, I also found this comment: > > #define Z_PARTIAL_FLUSH 1 /* will be removed, use Z_SYNC_FLUSH instead */ > #define Z_SYNC_FLUSH 2 > > The difference between sync flush and partial flush is that sync flush > would add an empty "store" block instead of the one or two empty deflate > blocks. The store block causes the next deflate block to start at a byte > boundary, but it uses up 4 more bytes than the empty deflate blocks. LSH happens to use Z_SYNC_FLUSH, and I haven't heard about any interoperability problems here, so I guess that is what everybody is doing. The relevant code is http://www.lysator.liu.se/~nisse/lsh/src/zlib.c. > Another compression-related issue whether when a new compression stream > starts (via SSH_MSG_NEWKEYS), the previous compression stream needs to > end normally (which for ZLIB involves appending an ADLER32 checksum), or > whether it can just terminate in the middle of the stream. My immediate reaction is to *not* append any adler32 checksum, for two reasons: (i) The MAC should already provide adequate integrity protection. (ii) I believe it would make the implementation more complicated, as you has to do something special for the last packet using the old compression context. It's probably not to painful to check for SSH_MSG_NEWKEYS (and SSH_MSG_DISCONNECT!) in the part of the code dealing with compression, but it is cleaner not to do that. /Niels From owner-ietf-ssh@clinet.fi Mon Sep 25 14:24:11 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10052 for ; Mon, 25 Sep 2000 14:24:10 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA06151 for ietf-ssh-outgoing; Mon, 25 Sep 2000 19:33:32 +0300 Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA06137 for ; Mon, 25 Sep 2000 19:33:30 +0300 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id JAA13512; Mon, 25 Sep 2000 09:33:28 -0700 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id JAA12675; Mon, 25 Sep 2000 09:33:27 -0700 (PDT) Date: Mon, 25 Sep 2000 09:33:25 -0700 From: Wei Dai To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: ietf-ssh@clinet.fi Subject: Re: meaning of partial flush Message-ID: <20000925093325.A784@eskimo.com> References: <20000921213614.E17038@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 1.0i In-Reply-To: ; from nisse@lysator.liu.se on Fri, Sep 22, 2000 at 12:49:21PM +0200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id TAA06151 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA10052 On Fri, Sep 22, 2000 at 12:49:21PM +0200, Niels Möller wrote: > LSH happens to use Z_SYNC_FLUSH, and I haven't heard about any > interoperability problems here, so I guess that is what everybody is > doing. It turns out things are a bit more complicated than that. OpenSSH seems to use Z_PARTIAL_FLUSH instead of Z_SYNC_FLUSH. I think this is actually a good idea because it causes less overhead than Z_SYNC_FLUSH. However even Z_PARTIAL_FLUSH sends more "filler" bits than is necessary because of the way the ZLIB decompression code is written. See this comment in trees.c: /* =========================================================================== * Send one empty static block to give enough lookahead for inflate. * This takes 10 bits, of which 7 may remain in the bit buffer. * The current inflate code requires 9 bits of lookahead. If the * last two codes for the previous block (real code plus EOB) were coded * on 5 bits or less, inflate may have only 5+3 bits of lookahead to decode * the last real code. In this case we send two empty static blocks instead * of one. (There are no problems if the previous block is stored or fixed.) * To simplify the code, we assume the worst case of last real code encoded * on one bit only. */ Someone who did not know about this implementation detail in ZLIB might think that sending just one empty static block would be sufficient in all cases. It really needs to be documented in the SSH specification that "partial flush" means either adding one empty store block, or two empty static blocks, even though adding just one empty static block would statisfy the purpose of flushing on the basis of RFC 1951. > My immediate reaction is to *not* append any adler32 checksum, for two > reasons: > > (i) The MAC should already provide adequate integrity protection. > > (ii) I believe it would make the implementation more complicated, as > you has to do something special for the last packet using the old > compression context. It's probably not to painful to check for > SSH_MSG_NEWKEYS (and SSH_MSG_DISCONNECT!) in the part of the code > dealing with compression, but it is cleaner not to do that. I agree with you on this. From owner-ietf-ssh@clinet.fi Mon Sep 25 14:39:18 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10444 for ; Mon, 25 Sep 2000 14:39:17 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA08476 for ietf-ssh-outgoing; Mon, 25 Sep 2000 19:50:58 +0300 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA08472 for ; Mon, 25 Sep 2000 19:50:57 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id E002E2401718; Mon, 25 Sep 2000 18:50:56 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id SAA06495; Mon, 25 Sep 2000 18:50:56 +0200 (MET DST) To: Wei Dai Cc: ietf-ssh@clinet.fi Subject: Re: meaning of partial flush References: <20000921213614.E17038@eskimo.com> <20000925093325.A784@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 From: nisse@lysator.liu.se (Niels Möller) Date: 25 Sep 2000 18:50:56 +0200 In-Reply-To: Wei Dai's message of "Mon, 25 Sep 2000 09:33:25 -0700" Message-ID: Lines: 33 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id TAA08476 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA10444 Wei Dai writes: > On Fri, Sep 22, 2000 at 12:49:21PM +0200, Niels Möller wrote: > > LSH happens to use Z_SYNC_FLUSH, and I haven't heard about any > > interoperability problems here, so I guess that is what everybody is > > doing. > > It turns out things are a bit more complicated than that. [ ... ] > However even Z_PARTIAL_FLUSH sends more "filler" bits than is necessary > because of the way the ZLIB decompression code is written. See this > comment in trees.c: Hmm. It's kind of ugly to depend on "the current inflate code". We're compressing sequences of blocks (octet strings of various sizes). For interoperability, the important conditions are that 1. The block sequence is one zlib stream, i.e. compression state is kept between blocks. 2. On block boundaries, enough syncing frames are added so that the receiving end can inflate the blocks one at a time. If more syncing than absolutely necessary is added, that should not cause any harm. But if I understand you correctly, (2) is not precise enough, one needs to add enough syncing frames to make a particular implementation happy. /Niels From owner-ietf-ssh@clinet.fi Mon Sep 25 14:52:41 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11014 for ; Mon, 25 Sep 2000 14:52:40 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA11321 for ietf-ssh-outgoing; Mon, 25 Sep 2000 20:05:46 +0300 Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA11307 for ; Mon, 25 Sep 2000 20:05:44 +0300 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id KAA27524; Mon, 25 Sep 2000 10:05:42 -0700 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id KAA14554; Mon, 25 Sep 2000 10:05:37 -0700 (PDT) Date: Mon, 25 Sep 2000 10:05:35 -0700 From: Wei Dai To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: ietf-ssh@clinet.fi Subject: Re: meaning of partial flush Message-ID: <20000925100535.B784@eskimo.com> References: <20000921213614.E17038@eskimo.com> <20000925093325.A784@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 1.0i In-Reply-To: ; from nisse@lysator.liu.se on Mon, Sep 25, 2000 at 06:50:56PM +0200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id UAA11321 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA11014 On Mon, Sep 25, 2000 at 06:50:56PM +0200, Niels Möller wrote: > Hmm. It's kind of ugly to depend on "the current inflate code". > > We're compressing sequences of blocks (octet strings of various > sizes). For interoperability, the important conditions are that > > 1. The block sequence is one zlib stream, i.e. compression state is > kept between blocks. > > 2. On block boundaries, enough syncing frames are added so that the > receiving end can inflate the blocks one at a time. If more syncing > than absolutely necessary is added, that should not cause any > harm. > > But if I understand you correctly, (2) is not precise enough, one > needs to add enough syncing frames to make a particular > implementation happy. Yes, exactly. It's unfortunate that up to now everyone has been using the same inflate implementation so nobody noticed this issue. Is it too late to ask the ZLIB maintainers to change their code, and just put (1) and (2) into the SSH spec? From owner-ietf-ssh@clinet.fi Mon Sep 25 20:59:28 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18632 for ; Mon, 25 Sep 2000 20:59:28 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA18542 for ietf-ssh-outgoing; Tue, 26 Sep 2000 02:05:11 +0300 Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA18539 for ; Tue, 26 Sep 2000 02:05:10 +0300 Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id CAA21420 for ; Tue, 26 Sep 2000 02:05:10 +0300 (EEST) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id CAA08469 for ietf-ssh@clinet.fi; Tue, 26 Sep 2000 02:05:09 +0300 (EET DST) From: Ssh Mailing List Administrator Received: from kansas.intranet.oz.is (scarecrow.oz.is [193.4.211.95]) by toto.oz.is (8.9.3/8.9.3) with ESMTP id MAA03590 for ; Wed, 13 Sep 2000 12:22:45 GMT Subject: Re: A comment on certificate-based server authentication and multiple DNS names To: ietf-ssh@clinet.fi X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000 Message-ID: Date: Wed, 13 Sep 2000 14:17:10 +0200 X-MIMETrack: Serialize by Router on OZ-ICE/OZ-Inc(Release 5.0.3 (Intl)|21 March 2000) at 13.09.2000 12:12:38 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ssh@clinet.fi Precedence: bulk --------------- On 12.09.2000 22:45:32 owner-ietf-ssh wrote: --------------- >> HTTPS has a big problem with #3 because they can not present multiple >> names with the same certificate. As SecSH does not yet deal in certificates, >> I suggest that the problem should be solved at that point. > >There is "insert certificate here" text in the current set of drafts. > > - Bill > I'd like to draw your attention to section 4.6, "Public Key Algorithms", of the current transport document draft ("draft-ietf-secsh-transport-07.txt"). This section lists several "Public Key Algorithms" that an implementation MAY support, among which is X.509 which is a certificate format. It even goes as far as specifying the binary format for an X.509 certificate, although it fails to specify which - if any - attributes of the certificate are to be used to certify which - if any - facts about the holder of the corresponding private key. BTW: I don't think that the fact that https/TLS isn't able to deal with multiple certificates in the single-IP multiple-names case, is valid justification for why SSH doesn't need to do so. One should generally strive to learn from past mistakes rather than to repeat them. --- Sigurdur Asgeirsson sigurasg@oz.com From owner-ietf-ssh@clinet.fi Mon Sep 25 21:01:23 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18671 for ; Mon, 25 Sep 2000 21:01:23 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA19894 for ietf-ssh-outgoing; Tue, 26 Sep 2000 02:15:30 +0300 Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA19891 for ; Tue, 26 Sep 2000 02:15:29 +0300 Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id CAA21621 for ; Tue, 26 Sep 2000 02:15:29 +0300 (EEST) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id CAA14923 for ietf-ssh@clinet.fi; Tue, 26 Sep 2000 02:15:29 +0300 (EET DST) From: Ssh Mailing List Administrator Received: from dorothy.int.sth.oz.com ([212.209.114.105]) by toto.oz.is (8.9.3/8.9.3) with ESMTP id NAA13242 for ; Thu, 14 Sep 2000 13:30:28 GMT Subject: Re: A comment on certificate-based server authentication and multiple DNS names To: ietf-ssh@clinet.fi X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000 Message-ID: Date: Thu, 14 Sep 2000 15:25:17 +0200 X-MIMETrack: Serialize by Router on OZ-STH/OZ-Inc(Release 5.0.3 (Intl)|21 March 2000) at 09/14/2000 03:20:00 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ssh@clinet.fi Precedence: bulk --------------- On 12.09.2000 22:45:32 owner-ietf-ssh wrote: --------------- >> HTTPS has a big problem with #3 because they can not present multiple >> names with the same certificate. As SecSH does not yet deal in certificates, >> I suggest that the problem should be solved at that point. > >There is "insert certificate here" text in the current set of drafts. > > - Bill > I'd like to draw your attention to section 4.6, "Public Key Algorithms", of the current transport document draft ("draft-ietf-secsh-transport-07.txt"). This section lists several "Public Key Algorithms" that an implementation MAY support, among which is X.509 which is a certificate format. It even goes as far as specifying the binary format for an X.509 certificate, although it fails to specify which - if any - attributes of the certificate are to be used to certify which - if any - facts about the holder of the corresponding private key. BTW: I don't think that the fact that https/TLS isn't able to deal with multiple certificates in the single-IP multiple-names case, is valid justification for why SSH doesn't need to do so. One should generally strive to learn from past mistakes rather than to repeat them. --- Sigurdur Asgeirsson sigurasg@oz.com From owner-ietf-ssh@clinet.fi Wed Sep 27 18:14:12 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23798 for ; Wed, 27 Sep 2000 18:14:11 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA27824 for ietf-ssh-outgoing; Wed, 27 Sep 2000 23:12:23 +0300 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA27820 for ; Wed, 27 Sep 2000 23:12:22 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 0CE4A240171E for ; Wed, 27 Sep 2000 22:12:22 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id WAA11672; Wed, 27 Sep 2000 22:12:21 +0200 (MET DST) To: ietf-ssh@clinet.fi Subject: Revising the document Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Möller) Date: 27 Sep 2000 22:12:21 +0200 Message-ID: Lines: 5 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I'd like to know who, if any, is working as document editor for revising the current drafts? Regards, /Niels From owner-ietf-ssh@clinet.fi Thu Sep 28 12:20:06 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25304 for ; Thu, 28 Sep 2000 12:20:05 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA26512 for ietf-ssh-outgoing; Thu, 28 Sep 2000 17:09:07 +0300 Received: from mailhost.man.brite.co.uk ([148.181.1.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA26481 for ; Thu, 28 Sep 2000 17:09:00 +0300 Received: from itmailman1.man.brite.co.uk (itmailman1.man.brite.co.uk [148.181.41.74]) by mailhost.man.brite.co.uk (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with ESMTP id PAA00104 for ; Thu, 28 Sep 2000 15:09:09 +0100 Received: by itmailman1.man.brite.co.uk with Internet Mail Service (5.5.2448.0) id ; Thu, 28 Sep 2000 15:09:09 +0100 Message-ID: <7D90C72D2739D311B4DA0090279361BD0104D9DE@itmailman1.man.brite.co.uk> From: "McKenzie, Andrew" To: "'ietf-ssh@clinet.fi'" Date: Thu, 28 Sep 2000 15:09:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk