From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu May 1 01:54:06 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6233C1A6F12 for ; Thu, 1 May 2014 01:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.251 X-Spam-Level: X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_SMALL=2.3, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UxbxtCshSCJ for ; Thu, 1 May 2014 01:54:05 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 949371A6F0E for ; Thu, 1 May 2014 01:54:05 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 4810314A2D5; Thu, 1 May 2014 08:54:01 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6A9A514A2C2 for ; Thu, 1 May 2014 08:53:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id csaKJE28kEGq for ; Thu, 1 May 2014 08:53:56 +0000 (UTC) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by mail.netbsd.org (Postfix) with ESMTP id 8A6F614A2C0 for ; Thu, 1 May 2014 08:53:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 55A6BBE68; Thu, 1 May 2014 09:53:51 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LczBFxWezKPH; Thu, 1 May 2014 09:53:51 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 45BCABE62; Thu, 1 May 2014 09:53:50 +0100 (IST) Message-ID: <53620B9E.6030201@cs.tcd.ie> Date: Thu, 01 May 2014 09:53:50 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: S Moonesamy CC: ietf-ssh@NetBSD.org Subject: AD review of draft-moonesamy-sshfp-ed25519-01 References: <6.2.5.6.2.20140430125433.0b637be0@elandsys.com> In-Reply-To: <6.2.5.6.2.20140430125433.0b637be0@elandsys.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi SM, all, I've agreed to AD sponsor this and so have done my AD review and have one question before I start IETF LC. Apologies if this was answered before;-) I'm still concerned if the format of the thing that is hashed is only defined in the SSH code. Is that the case? If so, what happens when someone else implements and does it differently and/or when we do have an ED25519 public key format in an RFC that's not the same as in the current code? Do we need another code point then? I'd be just fine if you wanted to add the public key format being used by SSH here and we add a new codepoint later if one is needed because we standardise a different format. Or, I'd be fine if you want to add a reference to some other specification (not necessarily an RFC) or even to a draft (though not sure there's a stable one there today). I note that RFC6594 contains examples of public key values that are hashed as well and this does not. I don't believe there's a shortage of codepoints here so adding another later isn't a problem from that POV but not sure what the implementers would want to do. But this question will be asked so I'd like to know the answer regardless of whether or not that means changes to this draft. The rest are nits that can be fixed now or later, but good to get done before IESG eval. 1) ID nits has two things: 1.1) == Unused Reference: 'RFC6594' is defined on line 109, but no explicit reference was found in the That's just in the acks, so I'm fine with it. But you could add a ref. 1.2) == Unused Reference: 'FIPS180-4' is defined on line 113, but no explicit reference was found in the text What's up there? How can a normative ref not be referred to? 2) The Reference for ed25519 isn't great. Isn't there anything better than that web site to add as well? (Keep the URL though.) Thanks, S. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu May 1 07:34:12 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BCE1A6EE6 for ; Thu, 1 May 2014 07:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.529 X-Spam-Level: X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, URI_HEX=1.122] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b18ZgudXx68K for ; Thu, 1 May 2014 07:34:11 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 11BF01A6F2F for ; Thu, 1 May 2014 07:34:11 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id B931614A2DC; Thu, 1 May 2014 14:34:06 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9395F14A2CE for ; Thu, 1 May 2014 14:33:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (1024-bit key) header.d=opendkim.org header.b=dC1KPx5a; dkim=pass (1024-bit key) header.d=elandsys.com header.b=bfOEKubC Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id F6LiB_a_GCo9 for ; Thu, 1 May 2014 14:33:58 +0000 (UTC) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by mail.netbsd.org (Postfix) with ESMTP id BD27414A2C8 for ; Thu, 1 May 2014 14:33:58 +0000 (UTC) Received: from SUBMAN.elandsys.com ([197.224.144.249]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s41EXa05026966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 May 2014 07:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1398954829; bh=+1RAE9z/fT4yR5LSz0pHxHcaWyNaLnslqj/OmdxORW8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dC1KPx5azYoIuiASCPHTBH+U9n/I8PhtPwQsflSOIXuingNaq9rVTPoxwZZrxmp5C k+CPxceFq5aAtbogY0zdA2o/ZM/L9RcR/rH29voK7XNHiXAFoP++wA1+qQrgsptGBG EvYo9xbDtJGIiCLrf02wTo1rzWeZkuC/90wi+DV0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1398954829; i=@elandsys.com; bh=+1RAE9z/fT4yR5LSz0pHxHcaWyNaLnslqj/OmdxORW8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bfOEKubCOjrVu3ClLCfPl+Z1DS8qE0EI9Dvg9Ml/Afc8myAcr7B0+aJ7Z9AeNCh6N id7Xfs+3Stx99cifPU/F/2y/pip7EowgEI/1n3+eSKiEhykqE5Y0G2MQIPTJAp7QMg lgcaqHnYpoQMQqrkPr+T/e4oQYvX0cWxxKcn8PnI= Message-Id: <6.2.5.6.2.20140501020701.0c06acf0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 01 May 2014 07:25:45 -0700 To: Stephen Farrell From: S Moonesamy Subject: Re: AD review of draft-moonesamy-sshfp-ed25519-01 Cc: ietf-ssh@NetBSD.org In-Reply-To: <53620B9E.6030201@cs.tcd.ie> References: <6.2.5.6.2.20140430125433.0b637be0@elandsys.com> <53620B9E.6030201@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Stephen, At 01:53 01-05-2014, Stephen Farrell wrote: >I've agreed to AD sponsor this and so have done my AD review >and have one question before I start IETF LC. Apologies if >this was answered before;-) Feel free to ask questions about the draft even if they have been asked previously. >I'm still concerned if the format of the thing that is >hashed is only defined in the SSH code. Is that the case? Yes. >If so, what happens when someone else implements and does >it differently and/or when we do have an ED25519 public >key format in an RFC that's not the same as in the current >code? Do we need another code point then? There is a Dropbear implementation (see https://matt.ucc.asn.au/dropbear/CHANGES ). There seems to be support in TTSSH ( http://sourceforge.jp/ticket/browse.php?group_id=1412&tid=33263 ) Currently, there are two implementations doing the same thing. That's good enough to consider assigning a code point. Ideally, there would be an ED25519 public key format documented in a RFC. There doesn't seem to be interest in standardizing a public key format. There is a possibility that another code point might be needed if someone goes and implement the thing differently. >I'd be just fine if you wanted to add the public key >format being used by SSH here and we add a new codepoint >later if one is needed because we standardise a different >format. Or, I'd be fine if you want to add a reference >to some other specification (not necessarily an RFC) or >even to a draft (though not sure there's a stable one >there today). There isn't an adequate specification. I doubt that there would be agreement on standardizing on a format. That's why the draft is intended as Informational. It's better than having an undocumented code point in use. I could add some text under Security Considerations: The public key fingerprint used for ED25519 in the SSHFP Resource Record relies on an undocumented OpenSSH public key format. >I note that RFC6594 contains examples of public key values >that are hashed as well and this does not. Yes. If I recall correctly I did not provide an example because of the above. >I don't believe there's a shortage of codepoints here >so adding another later isn't a problem from that POV >but not sure what the implementers would want to do. > >But this question will be asked so I'd like to know the >answer regardless of whether or not that means changes >to this draft. I would like other implementers (and anyone else) to comment about this even if it can end up being a problem for me. >The rest are nits that can be fixed now or later, but good >to get done before IESG eval. > >1) ID nits has two things: > >1.1) > == Unused Reference: 'RFC6594' is defined on line 109, but no explicit > reference was found in the That is because I added a credit for the author of that RFC. >That's just in the acks, so I'm fine with it. But you could add >a ref. I'll drop the RFC number from the text as I prefer to provide references which a reader might find useful to understand the document. >1.2) > == Unused Reference: 'FIPS180-4' is defined on line 113, but no > explicit reference was found in the text > >What's up there? How can a normative ref not be referred to? The reference was dropped when I removed a paragraph. I'll have: The SSHFP Resource Record for the ED25519 public key with SHA-256 fingerprint [FIPS180-4] would, for example, be: I am okay with moving it to an informative reference or not having the reference. >2) The Reference for ed25519 isn't great. Isn't there anything better >than that web site to add as well? (Keep the URL though.) I spent some time trying to find the most appropriate reference for ed25519 as I expected questions about that. Most of the web pages I read reference the original paper ( http://ed25519.cr.yp.to/ed25519-20110926.pdf ). I'll encourage people to review that and raise objections, if they consider it important, as it might help other people who are looking for an appropriate reference for ed25519. Regards, S. Moonesamy From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu May 1 07:44:09 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F3F1A6EE6 for ; Thu, 1 May 2014 07:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, URI_HEX=1.122] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMVTYCmDtoW7 for ; Thu, 1 May 2014 07:44:08 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 014DB1A084B for ; Thu, 1 May 2014 07:44:08 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 0558D14A2DE; Thu, 1 May 2014 14:44:05 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 09B6F14A2DC for ; Thu, 1 May 2014 14:43:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id i3GzC4pnxTef for ; Thu, 1 May 2014 14:43:56 +0000 (UTC) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by mail.netbsd.org (Postfix) with ESMTP id B176314A2D7 for ; Thu, 1 May 2014 14:43:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8F75ABE5F; Thu, 1 May 2014 15:43:50 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H29Cf0aLKcBz; Thu, 1 May 2014 15:43:50 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 42599BE6E; Thu, 1 May 2014 15:43:50 +0100 (IST) Message-ID: <53625DA6.9040700@cs.tcd.ie> Date: Thu, 01 May 2014 15:43:50 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: S Moonesamy CC: ietf-ssh@NetBSD.org Subject: Re: AD review of draft-moonesamy-sshfp-ed25519-01 References: <6.2.5.6.2.20140430125433.0b637be0@elandsys.com> <53620B9E.6030201@cs.tcd.ie> <6.2.5.6.2.20140501020701.0c06acf0@elandnews.com> In-Reply-To: <6.2.5.6.2.20140501020701.0c06acf0@elandnews.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hiya, I'm ok with moving ahead on the codepoint, but just one follow-up: if we do have 2 interoperable implementations could one of those maybe provide example public keys as they've hashed them (and a matching hash example of course). If that's easy then I think it'd be good to do even if there's no current good spec on the format. (I do expect we'll end up with one later, but could be a while all right.) I'll start the IETF LC now though and note this in that so's we're clear that we're clear if nobody comments on this during IETF LC (the IESG will defo. spot this:-) S. On 01/05/14 15:25, S Moonesamy wrote: > Hi Stephen, > At 01:53 01-05-2014, Stephen Farrell wrote: >> I've agreed to AD sponsor this and so have done my AD review >> and have one question before I start IETF LC. Apologies if >> this was answered before;-) > > Feel free to ask questions about the draft even if they have been asked > previously. > >> I'm still concerned if the format of the thing that is >> hashed is only defined in the SSH code. Is that the case? > > Yes. > >> If so, what happens when someone else implements and does >> it differently and/or when we do have an ED25519 public >> key format in an RFC that's not the same as in the current >> code? Do we need another code point then? > > There is a Dropbear implementation (see > https://matt.ucc.asn.au/dropbear/CHANGES ). There seems to be support > in TTSSH ( > http://sourceforge.jp/ticket/browse.php?group_id=1412&tid=33263 ) > Currently, there are two implementations doing the same thing. That's > good enough to consider assigning a code point. > > Ideally, there would be an ED25519 public key format documented in a > RFC. There doesn't seem to be interest in standardizing a public key > format. There is a possibility that another code point might be needed > if someone goes and implement the thing differently. > >> I'd be just fine if you wanted to add the public key >> format being used by SSH here and we add a new codepoint >> later if one is needed because we standardise a different >> format. Or, I'd be fine if you want to add a reference >> to some other specification (not necessarily an RFC) or >> even to a draft (though not sure there's a stable one >> there today). > > There isn't an adequate specification. I doubt that there would be > agreement on standardizing on a format. That's why the draft is > intended as Informational. It's better than having an undocumented code > point in use. > > I could add some text under Security Considerations: > > The public key fingerprint used for ED25519 in the SSHFP Resource > Record relies > on an undocumented OpenSSH public key format. > >> I note that RFC6594 contains examples of public key values >> that are hashed as well and this does not. > > Yes. If I recall correctly I did not provide an example because of the > above. > >> I don't believe there's a shortage of codepoints here >> so adding another later isn't a problem from that POV >> but not sure what the implementers would want to do. >> >> But this question will be asked so I'd like to know the >> answer regardless of whether or not that means changes >> to this draft. > > I would like other implementers (and anyone else) to comment about this > even if it can end up being a problem for me. > >> The rest are nits that can be fixed now or later, but good >> to get done before IESG eval. >> >> 1) ID nits has two things: >> >> 1.1) >> == Unused Reference: 'RFC6594' is defined on line 109, but no explicit >> reference was found in the > > That is because I added a credit for the author of that RFC. > >> That's just in the acks, so I'm fine with it. But you could add >> a ref. > > I'll drop the RFC number from the text as I prefer to provide references > which a reader might find useful to understand the document. > >> 1.2) >> == Unused Reference: 'FIPS180-4' is defined on line 113, but no >> explicit reference was found in the text >> >> What's up there? How can a normative ref not be referred to? > > The reference was dropped when I removed a paragraph. > > I'll have: > > The SSHFP Resource Record for the ED25519 public key with SHA-256 > fingerprint [FIPS180-4] would, for example, be: > > I am okay with moving it to an informative reference or not having the > reference. > >> 2) The Reference for ed25519 isn't great. Isn't there anything better >> than that web site to add as well? (Keep the URL though.) > > I spent some time trying to find the most appropriate reference for > ed25519 as I expected questions about that. Most of the web pages I > read reference the original paper ( > http://ed25519.cr.yp.to/ed25519-20110926.pdf ). I'll encourage people > to review that and raise objections, if they consider it important, as > it might help other people who are looking for an appropriate reference > for ed25519. > > Regards, > S. Moonesamy > > From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu May 1 08:02:17 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D61C1A08E9 for ; Thu, 1 May 2014 08:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v0Gpj1d6TRI for ; Thu, 1 May 2014 08:02:16 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEFD1A08E1 for ; Thu, 1 May 2014 08:02:16 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id B7C1E14A291; Thu, 1 May 2014 15:02:12 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id F277414A254 for ; Thu, 1 May 2014 15:02:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 1eCM7YC6Zc9x for ; Thu, 1 May 2014 15:02:07 +0000 (UTC) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by mail.netbsd.org (Postfix) with ESMTP id 4CEEF14A1EA for ; Thu, 1 May 2014 15:02:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 87129BE6E for ; Thu, 1 May 2014 16:02:06 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5Y2qjvGIANi for ; Thu, 1 May 2014 16:02:06 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 450ABBE62 for ; Thu, 1 May 2014 16:02:06 +0100 (IST) Message-ID: <536261EE.2040209@cs.tcd.ie> Date: Thu, 01 May 2014 16:02:06 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Fwd: Last Call: (Using ED25519 in SSHFP Resource Records) to Informational RFC References: <20140501145735.18958.1971.idtracker@ietfa.amsl.com> In-Reply-To: <20140501145735.18958.1971.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20140501145735.18958.1971.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list FYI, IETF LC has started. -------- Original Message -------- Subject: Last Call: (Using ED25519 in SSHFP Resource Records) to Informational RFC Date: Thu, 01 May 2014 07:57:35 -0700 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'Using ED25519 in SSHFP Resource Records' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-05-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Ed25519 signature algorithm has been implemented in OpenSSH. This document updates the IANA "SSHFP RR Types for public key algorithms" registry by adding an algorithm number for Ed25519. The file can be obtained via http://datatracker.ietf.org/doc/draft-moonesamy-sshfp-ed25519/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-moonesamy-sshfp-ed25519/ballot/ No IPR declarations have been submitted directly on this I-D. Note that there is no current standardised format for the input to the hash function here, but there are two implementations of this so a codepoint is needed and useful. A standard public key format is likely to be developed in future (but could take some time) at which point it may make sense to assign another codepoint, but there are no issues with codepoint scarcity here so that seems like it will work given the implemeners seem ok with it, even if its not ideal. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu May 1 08:15:28 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AA01A0904 for ; Thu, 1 May 2014 08:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uBFyFD8Fa49 for ; Thu, 1 May 2014 08:15:27 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 589691A07B3 for ; Thu, 1 May 2014 08:15:27 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 0A98C14A291; Thu, 1 May 2014 15:15:23 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 8323E14A23D for ; Thu, 1 May 2014 15:15:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (1024-bit key) header.d=opendkim.org header.b=Bw5c2c9l; dkim=pass (1024-bit key) header.d=elandsys.com header.b=PebZc3vK Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id rRNV8ztsDKz0 for ; Thu, 1 May 2014 15:15:19 +0000 (UTC) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by mail.netbsd.org (Postfix) with ESMTP id C477314A1F7 for ; Thu, 1 May 2014 15:15:19 +0000 (UTC) Received: from SUBMAN.elandsys.com ([197.224.144.249]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s41FF3j7014465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 May 2014 08:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1398957315; bh=Na5Pihd9QEq1YCEMLZKSq15BDnDCpqO1sQXojkR7nBU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Bw5c2c9lQaUYHtm8zjHBW+hhvoSD7zQwLYtWL9muVP/n+z0QEwIbHtmym78yDFWqd y1JvqyUhiXZOI9EmYQ5IyoOj2tkL8Kw7WccGQGz5qZS5+/vy0zr3ja3xOyFbjmWMg7 aq/olI+p0yqDbYuMayzKYgoc486FwG38Ve4EtMGM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1398957315; i=@elandsys.com; bh=Na5Pihd9QEq1YCEMLZKSq15BDnDCpqO1sQXojkR7nBU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PebZc3vK2hI0OGHXdM2M7OUZrAExLeHGU/bfj6s0thluRWDGxecY8g739N1+NkX7B q9ZKYOJ6pwXmiqSgYX4VGYRm7Q0RadslCg4KNIUsF/+LJQmglHR5kunFRVW60axyY5 OJocKDykVGx0QIbFP8HWFa2OqUxr9uGFBCh2Rqt8= Message-Id: <6.2.5.6.2.20140501075108.0aa2bfc8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 01 May 2014 08:07:27 -0700 To: Stephen Farrell From: S Moonesamy Subject: Re: AD review of draft-moonesamy-sshfp-ed25519-01 Cc: ietf-ssh@NetBSD.org In-Reply-To: <53625DA6.9040700@cs.tcd.ie> References: <6.2.5.6.2.20140430125433.0b637be0@elandsys.com> <53620B9E.6030201@cs.tcd.ie> <6.2.5.6.2.20140501020701.0c06acf0@elandnews.com> <53625DA6.9040700@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Stephen, At 07:43 01-05-2014, Stephen Farrell wrote: >I'm ok with moving ahead on the codepoint, but just one >follow-up: if we do have 2 interoperable implementations >could one of those maybe provide example public keys as >they've hashed them (and a matching hash example of course). I'll look into that and get back to you before the end of the Last Call. >If that's easy then I think it'd be good to do even if >there's no current good spec on the format. (I do expect >we'll end up with one later, but could be a while all >right.) I'll get the information and you get to make the call. :-) >I'll start the IETF LC now though and note this in that >so's we're clear that we're clear if nobody comments on >this during IETF LC (the IESG will defo. spot this:-) Thanks. Let's see what the IESG says. :-) Regards, S. Moonesamy From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun May 4 22:57:35 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B8F1A025A for ; Sun, 4 May 2014 22:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Wn_axGJBCIZ for ; Sun, 4 May 2014 22:57:34 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 57AE01A0254 for ; Sun, 4 May 2014 22:57:34 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id E006D14A1D4; Mon, 5 May 2014 05:57:28 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 05DD414A11C for ; Mon, 5 May 2014 05:57:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id WwdLC8YIIICj for ; Mon, 5 May 2014 05:57:24 +0000 (UTC) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by mail.netbsd.org (Postfix) with ESMTP id 1CB8814A317 for ; Mon, 5 May 2014 05:57:23 +0000 (UTC) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 6A71D3941BC; Mon, 5 May 2014 07:57:21 +0200 (CEST) Date: Mon, 05 May 2014 07:57:20 +0200 (CEST) Message-Id: <20140505.075720.274914921.mbj@tail-f.com> To: nisse@lysator.liu.se Cc: jhutz@cmu.edu, ietf-ssh@NetBSD.org, netmod@ietf.org Subject: Re: SSH keys - draft-ietf-netmod-system-mgmt From: Martin Bjorklund In-Reply-To: References: <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list nisse@lysator.liu.se (Niels M=F6ller) wrote: > Jeffrey Hutzelman writes: > = > > On Wed, 2014-04-30 at 08:49 +0200, Niels M=F6ller wrote: > >> > However, if we also keep the leaf algorithm, we need to spec= ify > >> > what happens if the leaf algorithm has a value that is diffe= rent > >> > from the value embedded in the key blob. > >> = > >> Right, eliminating this redundancy makes things simpler. > > > > It would, except you can't eliminate it. > = > Hmm. I think you're right. So then then the "algorithm" leaf would be= > the name being used in algorithm negotiation and the like, and the "k= ey" > leaf would be the key blob. The key blob typically starts with a stri= ng > containing the algorithm identifier, but nothing but the ssh > implementation is expected to care about that detail. Ok. But even if I don't know/care about the details; if I want to configure a key, I need to know that the format my keygen program uses is compatible with the format the server expects. > So then the right choice is 1), > = > : 1) Clarify that the leaf "key-data" contains: > : = > : string certificate or public key format identifier > : byte[n] key/certificate data > : = > : This allows for simple copy-and-paste from normal open ssh and > : rfc4716 files. But Jeffrey Hutzelman wrote: But yes, I believe RFC4716 is broken, because it relies on the encoding described above, rather than being consistent with the requirement "The key type MUST always be explicitly known." So if we introduce the clarification (1) above, aren't we doing the same mistake as RFC 4716? I am a bit confused by the terminology. What is the difference between "key", "key data", and "key blob"? /martin From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun May 4 23:57:47 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD2D1A026A for ; Sun, 4 May 2014 23:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lf_kbqw2sRJ9 for ; Sun, 4 May 2014 23:57:46 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 045691A0019 for ; Sun, 4 May 2014 23:57:46 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id B2B9214A1CA; Mon, 5 May 2014 06:57:39 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 29DBF14A1B9 for ; Mon, 5 May 2014 06:57:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id bh89ccKfgj_Z for ; Mon, 5 May 2014 06:57:33 +0000 (UTC) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 15A5114A1B8 for ; Mon, 5 May 2014 06:57:31 +0000 (UTC) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s456vLM1027931; Mon, 5 May 2014 08:57:21 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s456vHVK027925; Mon, 5 May 2014 08:57:17 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Martin Bjorklund Cc: jhutz@cmu.edu, ietf-ssh@NetBSD.org, netmod@ietf.org Subject: Re: SSH keys - draft-ietf-netmod-system-mgmt References: <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> <20140505.075720.274914921.mbj@tail-f.com> Date: Mon, 05 May 2014 08:57:17 +0200 In-Reply-To: <20140505.075720.274914921.mbj@tail-f.com> (Martin Bjorklund's message of "Mon, 05 May 2014 07:57:20 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Martin Bjorklund writes: > nisse@lysator.liu.se (Niels Möller) wrote: >> So then the right choice is 1), >> >> : 1) Clarify that the leaf "key-data" contains: >> : >> : string certificate or public key format identifier >> : byte[n] key/certificate data >> : >> : This allows for simple copy-and-paste from normal open ssh and >> : rfc4716 files. > > But Jeffrey Hutzelman wrote: > > But yes, I believe RFC4716 is broken, because it relies on the > encoding described above, rather than being consistent with the > requirement "The key type MUST always be explicitly known." It would have made some sense for the RFC 4716 public key format to include some other header for the algorithm, but I'm not sure it's "broken". I think one reasonable interpretation of "The key type MUST always be explicitly known." is that it's inappropriate to define mechanisms *within* the ssh protocol which accept a key of arbitrary type, without any algorithm negotiation or advertisement, so that the receiver has to take the key apart and then do some dispatch on the embedded algorithm type. But that doens't necessarily rule out passing around arbitrary keys *outside* of the ssh wire protocol, without specifying key type explicitly. > I am a bit confused by the terminology. What is the difference > between "key", "key data", and "key blob"? Sorry about that. I think the data for the "key-data" leaf should be as you specify it above. E.g., for an RSA key, the ssh transport encoding of string "ssh-rsa" mpint e mpint n The one thing that seems clear to me is that you shouldn't strip that algorithm field from your "key-data" leaf. > So if we introduce the clarification (1) above, aren't we doing the > same mistake as RFC 4716? If you also include the string "ssh-rsa" in the "algorithm" leaf, you *do* have that extra information, missing from RFC 4716. So if it's a mistake, it's a different mistake. A small practical problem is that if you want to do simple copy-and-paste from rfc4716 files, you also need a tool to extract the algorithm identifier, so you can set the "algorithm" leaf correctly. And I see nothing wrong in doing that; it is properly specified in both RFC 4716 and RFC4253 how to do that, and any tools handing RFC4716 files at all can be expected to have some knowledge of ssh specifics. I have to admit I'm also a bit confused at this point... it's getting less and less clear to me if it really is the right thing to include algorithm info separately. My gut reaction was no, and then Jeffrey convinced me it's necessary, and now I just don't know. Pro: Having the algorithm separately simplifies some use cases. Say, you want to compare the information in your files to the configuration of an ssh implementation to see if available keys are supported. Cons: You could get subtle failure modes if you do the above, and the data is inconsistent. Say some program ignores your algorithm leaf (e.g., you export the key data in RFC 4716 format), and some doesn't (e.g., the algorithm leaf makes it through to the ssh configuration, and then the key is invalid, and results in an error locally or remotely). Probably no *big* problems either way. In case you use this data to keep track of authorized user or host keys, I think it's prudent to make sure than any key-data leaf not matching the corresponding "algorithm" leafs is treated as an invalid key. And, e.g., refuse to export it in RFC 4716 format. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon May 5 12:39:38 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7061A01BC for ; Mon, 5 May 2014 12:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEGHgwgPt2WZ for ; Mon, 5 May 2014 12:39:32 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id BEA721A01B2 for ; Mon, 5 May 2014 12:39:32 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 3759414A3B5; Mon, 5 May 2014 19:39:27 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E889B14A3B4 for ; Mon, 5 May 2014 19:39:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id u1M2WB9peJeH for ; Mon, 5 May 2014 19:39:24 +0000 (UTC) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by mail.netbsd.org (Postfix) with ESMTP id 2759F14A3B1 for ; Mon, 5 May 2014 19:39:24 +0000 (UTC) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id PAA04252; Mon, 5 May 2014 15:39:23 -0400 (EDT) Date: Mon, 5 May 2014 15:39:23 -0400 (EDT) From: Mouse Message-Id: <201405051939.PAA04252@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Mon, 5 May 2014 15:23:42 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Albrecht/Paterson/Watson's attack Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Perhaps it wasn't mentioned here, or perhaps I'd just missed it, but a note elselist prompted me to read http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf. Any thoughts? Besides the obvious suggestions made in the paper (basically "don't use CBC bulk ciphers"), it occurs to me that there is another defense: make it hard to identify packet boundaries by, whenever the connection would otherwise go idle, generating an IGNORE packet and sending only part of it, holding the rest until something more is available to be sent on that connection. It wouldn't completely prevent the attack, since the attacker can simply guess how much BPP-level packet remains at the network-level packet boundary, but it would be another factor against success - and it would require not just injecting data, but intercepting and modifying the first wire packet after idle time. It would also render connections attackable only during the first packet after idle time, rather than at any time when idle. It seems to me this would increase the difficulty of an attack, perhaps significantly. While admittedly this particular attack is easy enough to defeat by just not using CBC modes, it seems likely to me that some other attack based on recognizing and exploiting BPP-layer packet boundaries will come along. Thoughts? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon May 5 15:43:38 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1176B1A048C for ; Mon, 5 May 2014 15:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcCuWJ0NFgwa for ; Mon, 5 May 2014 15:43:33 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 615081A0481 for ; Mon, 5 May 2014 15:43:33 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 4937014A3EE; Mon, 5 May 2014 22:43:27 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 22D8714A3D8 for ; Mon, 5 May 2014 22:43:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id PH8P_ZWtAdB8 for ; Mon, 5 May 2014 22:43:23 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 034DF14A3C9 for ; Mon, 5 May 2014 22:43:22 +0000 (UTC) Received: from BY2PR05CA001.namprd05.prod.outlook.com (10.242.32.31) by CO2PR0501MB920.namprd05.prod.outlook.com (10.141.247.23) with Microsoft SMTP Server (TLS) id 15.0.929.12; Mon, 5 May 2014 22:10:12 +0000 Received: from BY2FFO11FD002.protection.gbl (2a01:111:f400:7c0c::106) by BY2PR05CA001.outlook.office365.com (2a01:111:e400:2c2a::31) with Microsoft SMTP Server (TLS) id 15.0.939.12 via Frontend Transport; Mon, 5 May 2014 22:10:11 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD002.mail.protection.outlook.com (10.1.14.124) with Microsoft SMTP Server (TLS) id 15.0.929.8 via Frontend Transport; Mon, 5 May 2014 22:10:11 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 5 May 2014 15:10:10 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s45M9gV91084; Mon, 5 May 2014 15:09:52 -0700 (PDT) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 7DE8111446; Mon, 5 May 2014 15:09:28 -0700 (PDT) To: Mouse CC: Subject: Re: Albrecht/Paterson/Watson's attack In-Reply-To: <201405051939.PAA04252@Chip.Rodents-Montreal.ORG> References: <201405051939.PAA04252@Chip.Rodents-Montreal.ORG> Comments: In-reply-to: Mouse message dated "Mon, 05 May 2014 15:39:23 -0400." From: "Mark D. Baushke" X-Mailer: MH-E 8.5; nmh 1.2; GNU Emacs 22.1.1 X-Face: #8D_6URD2G%vC.hzU MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.16;CTRY:US;IPV:NLI;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10009001)(6009001)(199002)(189002)(77982001)(19580405001)(81542001)(81342001)(62966002)(4396001)(88136002)(48376002)(6806004)(76176999)(47776003)(84676001)(87286001)(92726001)(97736001)(74662001)(31966008)(44976005)(99396002)(50226001)(76482001)(50986999)(2009001)(15975445006)(74502001)(20776003)(89996001)(87936001)(92566001)(77096999)(93916002)(77156001)(83072002)(86362001)(15202345003)(19580395003)(80022001)(46102001)(50466002)(85852003)(83322001)(79102001)(53416003)(42262001);DIR:OUT;SFP:1101;SCL:1;SRVR:CO2PR0501MB920;H:P-EMF02-SAC.jnpr.net;FPR:FC75F531.B934C5C9.70F18F5E.8CED9080.20231;MLV:sfv;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Forefront-PRVS: 0202D21D2F Received-SPF: SoftFail (: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) X-OriginatorOrg: juniper.net Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Mouse writes: > Besides the obvious suggestions made in the paper (basically "don't > use CBC bulk ciphers"), it occurs to me that there is another defense: > make it hard to identify packet boundaries by, whenever the connection > would otherwise go idle, generating an IGNORE packet and sending only > part of it, holding the rest until something more is available to be > sent on that connection. Another alternative is to use an encrypt-then-mac approach. http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-05 which has a normative reference to: Krawczyk, H., "The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?)", Springer-Verlag LNCS 2139, August 2001. fwiw: I believe that OpenSSL extensions to KEX_DEFAULT_MAC do this: "hmac-md5-etm@openssh.com," \ "hmac-sha1-etm@openssh.com," \ "umac-64-etm@openssh.com," \ "umac-128-etm@openssh.com," \ "hmac-sha2-256-etm@openssh.com," \ "hmac-sha2-512-etm@openssh.com," \ "hmac-ripemd160-etm@openssh.com," \ "hmac-sha1-96-etm@openssh.com," \ "hmac-md5-96-etm@openssh.com," \ which seems to work for them. I don't know if we want to try to make the -etm alternatives available as a part of the SSHv2 defined set of MACs. -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon May 5 17:20:14 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760F21A01B9 for ; Mon, 5 May 2014 17:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, STOX_REPLY_TYPE=0.439] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBDraRHjwVUL for ; Mon, 5 May 2014 17:20:02 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD851A0045 for ; Mon, 5 May 2014 17:20:02 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id F24BE14A414; Tue, 6 May 2014 00:19:55 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 8BB0E14A413 for ; Tue, 6 May 2014 00:19:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id AFm5qbFR0PgR for ; Tue, 6 May 2014 00:19:50 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 81B9014A412 for ; Tue, 6 May 2014 00:19:50 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher AES128-SHA256 (128 bits)); Tue, 6 May 2014 01:15:28 +0100 Message-ID: From: "denis bider \(Bitvise\)" To: "Mouse" , References: <201405051939.PAA04252@Chip.Rodents-Montreal.ORG> In-Reply-To: <201405051939.PAA04252@Chip.Rodents-Montreal.ORG> Subject: Re: Albrecht/Paterson/Watson's attack Date: Mon, 5 May 2014 18:15:39 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Our implementation in Bitvise SSH Server (versions of the last several years that use our FlowSsh library) makes this class of attack difficult by: - Implementing precise checks about whether the received packet length is valid. - If the received packet length is invalid, generating a random valid packet length, and continuing execution as if that length was received. This way, the attacker is denied knowledge of whether their attempt to infiltrate the first CBC block succeeded or not. I know of no way the attacker can distinguish one successful infiltration attempt from hundreds of thousands of unsuccessful attempts. Even if the attacker knows some property of the plaintext, e.g. that it is ASCII, many of the unsuccessful "plaintexts" can seem valid. denis -----Original Message----- From: Mouse Sent: Monday, May 5, 2014 13:39 To: ietf-ssh@netbsd.org Subject: Albrecht/Paterson/Watson's attack Perhaps it wasn't mentioned here, or perhaps I'd just missed it, but a note elselist prompted me to read http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf. Any thoughts? Besides the obvious suggestions made in the paper (basically "don't use CBC bulk ciphers"), it occurs to me that there is another defense: make it hard to identify packet boundaries by, whenever the connection would otherwise go idle, generating an IGNORE packet and sending only part of it, holding the rest until something more is available to be sent on that connection. It wouldn't completely prevent the attack, since the attacker can simply guess how much BPP-level packet remains at the network-level packet boundary, but it would be another factor against success - and it would require not just injecting data, but intercepting and modifying the first wire packet after idle time. It would also render connections attackable only during the first packet after idle time, rather than at any time when idle. It seems to me this would increase the difficulty of an attack, perhaps significantly. While admittedly this particular attack is easy enough to defeat by just not using CBC modes, it seems likely to me that some other attack based on recognizing and exploiting BPP-layer packet boundaries will come along. Thoughts? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon May 5 23:51:37 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0321A025F for ; Mon, 5 May 2014 23:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFepBZ2ckeSl for ; Mon, 5 May 2014 23:51:36 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9C01A025E for ; Mon, 5 May 2014 23:51:36 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 4252914A276; Tue, 6 May 2014 06:51:30 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 83F6314A274 for ; Tue, 6 May 2014 06:51:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id mRM0LaeFexW9 for ; Tue, 6 May 2014 06:51:28 +0000 (UTC) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A751214A270 for ; Tue, 6 May 2014 06:51:26 +0000 (UTC) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s466pObH024787; Tue, 6 May 2014 08:51:24 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s466pN7a024786; Tue, 6 May 2014 08:51:23 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Mouse Cc: ietf-ssh@netbsd.org Subject: Re: Albrecht/Paterson/Watson's attack References: <201405051939.PAA04252@Chip.Rodents-Montreal.ORG> Date: Tue, 06 May 2014 08:51:23 +0200 In-Reply-To: <201405051939.PAA04252@Chip.Rodents-Montreal.ORG> (mouse@rodents-montreal.org's message of "Mon, 5 May 2014 15:39:23 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Mouse writes: > make it hard to identify packet boundaries by, > whenever the connection would otherwise go idle, generating an IGNORE > packet and sending only part of it, holding the rest until something > more is available to be sent on that connection. I think that's a good idea in general, also to make traffic analysis a bit more difficult. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon May 5 23:57:27 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9EA1A025F for ; Mon, 5 May 2014 23:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJP4dcR0vTUp for ; Mon, 5 May 2014 23:57:26 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 55B5E1A025E for ; Mon, 5 May 2014 23:57:26 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 0FFA714A28C; Tue, 6 May 2014 06:57:21 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4539414A288 for ; Tue, 6 May 2014 06:57:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id tI7wIm0SHTwe for ; Tue, 6 May 2014 06:57:17 +0000 (UTC) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 43B4214A286 for ; Tue, 6 May 2014 06:57:17 +0000 (UTC) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s466vBs9024862; Tue, 6 May 2014 08:57:11 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s466vBiJ024861; Tue, 6 May 2014 08:57:11 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: "Mark D. Baushke" Cc: Mouse , Subject: Re: Albrecht/Paterson/Watson's attack References: <201405051939.PAA04252@Chip.Rodents-Montreal.ORG> <2502.1399327766@eng-mail01.juniper.net> Date: Tue, 06 May 2014 08:57:11 +0200 In-Reply-To: <2502.1399327766@eng-mail01.juniper.net> (Mark D. Baushke's message of "Mon, 5 May 2014 15:09:26 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list "Mark D. Baushke" writes: > fwiw: I believe that OpenSSL extensions to KEX_DEFAULT_MAC do this: > > "hmac-md5-etm@openssh.com," \ > "hmac-sha1-etm@openssh.com," \ > "umac-64-etm@openssh.com," \ > "umac-128-etm@openssh.com," \ > "hmac-sha2-256-etm@openssh.com," \ > "hmac-sha2-512-etm@openssh.com," \ > "hmac-ripemd160-etm@openssh.com," \ > "hmac-sha1-96-etm@openssh.com," \ > "hmac-md5-96-etm@openssh.com," \ > > which seems to work for them. I don't know if we want to try to make the > -etm alternatives available as a part of the SSHv2 defined set of MACs. I think that would be good. Back when the ssh protocols were designed, applying the MAC to the cleartext was uncontroversial. I think Schneier's Applied Cryptography recommended it, with the motivation that message authentication ought to be applied to the data that has meaning to the receiver. A possible attack was that the enemy might tamper with the encryption key used; this clearly changes the cleartext message, but if the MAC is applied to the cryptotext, that type of change isn't detected. The somewhat counter intuitive advice that the MAC should be applied to the cryptotext is more recent, and if it's not too painful to incorporate that in ssh in general, that would be a good thing. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue May 6 03:01:11 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFBE1A079C for ; Tue, 6 May 2014 03:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_W8c9KtK06a for ; Tue, 6 May 2014 03:01:09 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id A38EC1A0798 for ; Tue, 6 May 2014 03:01:09 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 6B8BE14A429; Tue, 6 May 2014 10:01:03 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 839B614A428 for ; Tue, 6 May 2014 10:01:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (1024-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id qefoPO_t9eqL for ; Tue, 6 May 2014 10:01:00 +0000 (UTC) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 663D014A41A for ; Tue, 6 May 2014 10:00:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1399370460; x=1430906460; h=date:message-id:from:to:subject:cc:in-reply-to; bh=tmMO/tZJmSAsFnCK2uwLkrwQ3Y8hBKToinYNz0O/poU=; b=epT5RDOpObIWopZZ5bWipZRaGl7jz3RWuhSwo7X4s+fwfD8EXfJ60iWz a5gnyg5uTFVERJ1gckl5h19yaD+G4608JS9kGFjoPTYAVstv4ee5xgQna p//muYb4Dq9EuGGJALlaUWBAmX81ULhL4RaSHBsyrpI5yR9QTsBNndbed k=; X-IronPort-AV: E=Sophos;i="4.97,996,1389697200"; d="scan'208";a="250713280" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.34.40 - Outgoing - Outgoing Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 May 2014 22:00:55 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.72) (envelope-from ) id 1WhcBC-0001yc-N3; Tue, 06 May 2014 22:00:54 +1200 Date: Tue, 06 May 2014 22:00:54 +1200 Message-Id: From: Peter Gutmann To: mdb@juniper.net, nisse@lysator.liu.se Subject: Re: Albrecht/Paterson/Watson's attack Cc: ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG In-Reply-To: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Niels Möller writes: >I think that would be good. +1 (conflict-of-interest disclaimer: I'm the author of the TLS EtM draft). One thing that SSH would then need to do is to stop encrypting the header (that is, the length information) so you can run the MAC over the packet without having to pick apart bits of it via decryption first, which is what helps the Paterson et al attack work. The TLS draft explicitly tells implementers to read the length, read that many bytes from the network, run the MAC, and discard the packet immediately if the MAC fails to verify. If you still need to run crypto ops before you can verify the MAC you're not actually doing EtM, or at least not getting the security benefits that it provides. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue May 6 03:25:22 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482BF1A02A1 for ; Tue, 6 May 2014 03:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7-mNLwFXoNA for ; Tue, 6 May 2014 03:25:20 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id D36271A0793 for ; Tue, 6 May 2014 03:25:20 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id ACFD214A436; Tue, 6 May 2014 10:25:15 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id CB62714A428 for ; Tue, 6 May 2014 10:25:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id o6t1cMEDw3Vi for ; Tue, 6 May 2014 10:25:11 +0000 (UTC) Received: from atreus.tartarus.org (atreus.tartarus.org [80.252.125.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E145814A25F for ; Tue, 6 May 2014 10:25:10 +0000 (UTC) Received: from simon by atreus.tartarus.org with local (Exim 4.69) (envelope-from ) id 1WhcYc-0005yv-Fw; Tue, 06 May 2014 11:25:06 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: pgut001@cs.auckland.ac.nz Cc: ietf-ssh@netbsd.org Subject: Re: Albrecht/Paterson/Watson's attack In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: Date: Tue, 06 May 2014 11:25:06 +0100 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list In article you write: > One thing that SSH would then need to do is to stop encrypting the header > (that is, the length information) so you can run the MAC over the packet > without having to pick apart bits of it via decryption first, which is what > helps the Paterson et al attack work. I think this idea has historically been unpopular in SSH circles because the cleartext packet length fields were critical to attacks against SSH-1. Of course, those were _particularly bad_ cleartext packet length fields, but even so, it's unsurprising that people have a reflexive aversion as a result... Personally, if I were redesigning the SSH-2 binary packet protocol, I'd be inclined to split it into two entirely separate layers, by removing the coupling between semantic SSH protocol messages and chunks of data encrypted/MACed as a whole. There's no actual reason that the two should coincide. So you'd start with a BPP designed solely for security, which would consist of a series of (length, encrypted data, MAC) chunks stuck end-to-end. The MAC would apply to the ciphertext, and the length would be the full length of the ciphertext (or perhaps ciphertext+MAC) in clear. Once those chunks were MACed and decrypted, the decrypted ciphertexts would be concatenated, and the resulting byte stream would be divided into semantic SSH-2 messages according to a (length, type, data) format about as simple as the one in SFTP (though you might also want to provide a convenient way of including small numbers of bytes of padding between messages, without having to construct an entire SSH_MSG_IGNORE). And the two notions of 'chunk' and 'message' have no particular need to match up. So if you wanted to send lots of SSH-2 messages in one go, you could combine them into a single chunk, and then the atomic MAC covering the whole chunk would make it impossible for an attacker to determine the boundaries between those messages (so, e.g., hiding password length by combining the password with an SSH_MSG_IGNORE is now clearly not defeatable by proxying the TCP stream and dribbling out bytes one by one until you see a response). Conversely, a very large message could be split across multiple chunks if you felt like it, or an SSH_MSG_IGNORE could start at the end of one chunk and finish in the start of the next. Hence, the cleartext length field on the _chunk_ doesn't necessarily tell you anything about the length of any _message_ within that chunk. Indeed, it doesn't even tell you anything you couldn't deduce from the TCP segment boundaries, which is my rationale for it not being an unreasonable exposure of information. (In particular, the cleartext length field would always be a multiple of the cipher block size.) I suppose, on the other hand, that if people still disliked having message lengths in clear, then you could tweak this concept using the suggestion from the paper referenced upthread of having a MAC covering just the length field or just the first cipher block or some such, so you'd get a chunk consisting of (encrypted length, MAC of encrypted length, encrypted rest-of-data, MAC of encrypted rest-of-data). -- Simon Tatham "A cynic is a person who smells flowers and immediately looks around for a coffin." From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue May 6 04:24:43 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CD31A02B2 for ; Tue, 6 May 2014 04:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4G-W9zTKHHZQ for ; Tue, 6 May 2014 04:24:42 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 1511D1A02B0 for ; Tue, 6 May 2014 04:24:42 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id DFF7914A450; Tue, 6 May 2014 11:24:32 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D8D5D14A44E for ; Tue, 6 May 2014 11:24:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id w_Roeopp1Rab for ; Tue, 6 May 2014 11:24:27 +0000 (UTC) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id CE0C514A25E for ; Tue, 6 May 2014 11:24:25 +0000 (UTC) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s46BOB5f000464; Tue, 6 May 2014 13:24:11 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s46BOA9N000458; Tue, 6 May 2014 13:24:10 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Simon Tatham Cc: pgut001@cs.auckland.ac.nz, ietf-ssh@netbsd.org Subject: Re: Albrecht/Paterson/Watson's attack References: Date: Tue, 06 May 2014 13:24:10 +0200 In-Reply-To: (Simon Tatham's message of "Tue, 06 May 2014 11:25:06 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Simon Tatham writes: > I suppose, on the other hand, that if people still disliked having > message lengths in clear, then you could tweak this concept using the > suggestion from the paper referenced upthread of having a MAC covering > just the length field or just the first cipher block or some such, so > you'd get a chunk consisting of (encrypted length, MAC of encrypted > length, encrypted rest-of-data, MAC of encrypted rest-of-data). I'm pretty sure I'm missing something subtle here. We first get a packet length, and then we read an encrypted message of that length from the network, check the mac and decrypt it (assuming we have configured some -etm mode of operation). To communicate that packet length, we have a couple of different options: 1. Cleartext packet length, no crypto, no mac. 2. Encrypted packet length, no mac. 3. Encrypted packet length, with a separate mac. You seem to be saying that (1) is secure (except that the exposed lengths are unfortunately meaningful also above the ssh transport layer) and that (3) is secure, but that (2) is a problem. Is there any easy explanation for that? I realize that the first decrypted block includes both length and a prefix of the cleartext message, which possibly is the source of the problem, but if everything but the length part is ignored until after successful verification of the mac, it's not clear why that's a problem. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue May 6 04:42:48 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96111A02AA for ; Tue, 6 May 2014 04:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68vTLXXP0hHG for ; Tue, 6 May 2014 04:42:47 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2671A02A1 for ; Tue, 6 May 2014 04:42:47 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 57DE114A296; Tue, 6 May 2014 11:42:42 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 37A0A14A291 for ; Tue, 6 May 2014 11:42:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id O6R-rILD4Pem for ; Tue, 6 May 2014 11:42:38 +0000 (UTC) Received: from atreus.tartarus.org (atreus.tartarus.org [80.252.125.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 668D414A27B for ; Tue, 6 May 2014 11:42:38 +0000 (UTC) Received: from simon by atreus.tartarus.org with local (Exim 4.69) (envelope-from ) id 1WhdlZ-00054G-0H; Tue, 06 May 2014 12:42:33 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham In-Reply-To: To: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Cc: pgut001@cs.auckland.ac.nz, ietf-ssh@netbsd.org Subject: Re: Albrecht/Paterson/Watson's attack MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: Date: Tue, 06 May 2014 12:42:33 +0100 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) wrote: > You seem to be saying that (1) is secure (except that the exposed > lengths are unfortunately meaningful also above the ssh transport layer) > and that (3) is secure, but that (2) is a problem. Sorry to have been unclear! I may well not have thought it through adequately myself. But what I was getting at here is two separate attacks: (a) the subject of the whole paper, i.e. an attack on the encryption which involves substituting an initial cipher block and inferring from the subsequent failure mode some information about the length field to which it decrypted. Putting the length field in cleartext rather than in the first cipher block defeats this attack. (b) the DoS attack which the paper mentions in passing as being potentially opened up by having the length field in cleartext: an active attacker replaces the length field with a very large one and sends a big pile of data, causing the receiver to buffer it all and use up a lot of memory. The paper admits that this may not be something you particularly care about. The option you list as (1), i.e. a cleartext unMACed packet length, defeats attack (a), but it struck me that people might still dislike cleartext packet lengths for some other reason(s), possibly including attack (b). Option (2), putting the packet length back into the encrypted data without a separate MAC, risks reintroducing forms of attack (a), i.e. decryption oracles based on the fact that the decrypted packet length affects the receiver's behaviour before the MAC on it is checked. Option (3), encrypting the packet length and MACing it separately, defeats both types of attack as far as I can see. (And I don't think it matters whether the packet length lives on its own in a separate cipher block or whether it's combined with the first n-4 bytes of the payload. As long as a fixed number of cipher blocks are covered by the first MAC, and that MAC is verified before taking any action based on the length field, I think it should be OK either way.) -- Simon Tatham "Happiness is having a large, warm, loving, caring, close-knit family in another city." From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue May 6 05:50:44 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E159F1A02F5 for ; Tue, 6 May 2014 05:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLUKFmhwoVnY for ; Tue, 6 May 2014 05:50:43 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 6507C1A0061 for ; Tue, 6 May 2014 05:50:43 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 4B00314A470; Tue, 6 May 2014 12:50:37 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2E5C414A46C for ; Tue, 6 May 2014 12:50:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id S6UNsYASm-qk for ; Tue, 6 May 2014 12:50:33 +0000 (UTC) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 310C314A466 for ; Tue, 6 May 2014 12:50:32 +0000 (UTC) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s46CoJkj001880; Tue, 6 May 2014 14:50:19 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s46CoH8b001878; Tue, 6 May 2014 14:50:17 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Simon Tatham Cc: pgut001@cs.auckland.ac.nz, ietf-ssh@netbsd.org Subject: Re: Albrecht/Paterson/Watson's attack References: Date: Tue, 06 May 2014 14:50:17 +0200 In-Reply-To: (Simon Tatham's message of "Tue, 06 May 2014 12:42:33 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Simon Tatham writes: > (a) the subject of the whole paper, i.e. an attack on the encryption > which involves substituting an initial cipher block and inferring > from the subsequent failure mode some information about the > length field to which it decrypted. Putting the length field in > cleartext rather than in the first cipher block defeats this > attack. If you said that the attacker can infer information about the initial cleartext, *after* the length field, then a cleartext length field might be an improvement. I imagine that attacks like that might be possible with CBC mode, but is seems highly unlikely if using something like aes-ctr or salsa20. But if the problem is leaking information about the length field itself, a change to instead send that information totally in the clear cannot be an improvement. To adress leaking of length info to active attackers, one would need a redesign where information about the length never reveals anything sensitive, a bit like what you sketched. I guess I ought to read the paper myself, but I don't have the time to do that right away. > Option (3), encrypting the packet length and MACing it separately, > defeats both types of attack as far as I can see. Given the close connection between ssh transport packets and packets for the userauth and connection protocols, I think it's desirable to encrypt the length (and in general, try to hide message boundaries). But an additional MAC gives a significant additional overhead. Maybe one could get away with a short MAC for the first block (including the length), provided that the MAC at the end of the cryptotext covers the complete message? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu May 8 14:45:06 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA5C1A0179 for ; Thu, 8 May 2014 14:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhRicr0N3KwG for ; Thu, 8 May 2014 14:45:05 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9001A0168 for ; Thu, 8 May 2014 14:45:05 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 6EA7414A25E; Thu, 8 May 2014 21:44:58 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9779D14A24C for ; Thu, 8 May 2014 21:44:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id ubrprm9563Vg for ; Thu, 8 May 2014 21:44:53 +0000 (UTC) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by mail.netbsd.org (Postfix) with ESMTP id 7417C14A24A for ; Thu, 8 May 2014 21:44:53 +0000 (UTC) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id RAA05625; Thu, 8 May 2014 17:44:40 -0400 (EDT) Date: Thu, 8 May 2014 17:44:40 -0400 (EDT) From: Mouse Message-Id: <201405082144.RAA05625@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 8 May 2014 16:22:28 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Albrecht/Paterson/Watson's attack In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > One thing that SSH would then need to do is to stop encrypting the > header (that is, the length information) so you can run the MAC over > the packet without having to pick apart bits of it via decryption > first, This is actually not quite true. It would need to do so to implement EtM as outlined in the descriptions I've found, but I see no particular reason to slavishly follow them. There's no reason you can't encrypt the whole thing, including the length, but then MAC the resulting ciphertext. You have to decrypt a little before you can tell how much to run the MAC over, but that's hardly a big deal. Personally, if I were worried about such things, I would probably MAC the cleartext, MAC the ciphertext, and append both MACs to the encrypted packet. I might even encrypt the cleartext's MAC along with the payload before running the ciphertext MAC. > If you still need to run crypto ops before you can verify the MAC > you're not actually doing EtM, or at least not getting the security > benefits that it provides. What benefits _does_ it provide? Why do they outweigh exposing packet sizes? It seems to me that the Bellare/Namprempre paper has a number of weaknesses for our purposes[%], mostly amounting to mismatches between its assumptions and the world of SSH. In particular, the only arguments I see against E&M, such as SSH uses, are based on the MAC leaking information about its input. It would be nice to use a construct that has some kind of proof of its security - other things being equal. Here, they are not; using their EtM construction demands exposing information the current paradigm does not expose. Furthermore, the only flaws I see described in the current construction are based on assuming weaknesses in the underlying algorithms. But I recognize your name enough to know you're not stupid. This leads me to expect I'm missing something important. What? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B [%] For example, it appears to assume that message lengths are unprotected in all variants; as I understand it, that's one of the main arguments against EtM for SSH. The paper also does not consider different types of brokenness different, such as implementation bugs that can break an algorithm in some ways but not others - an example is the "what if the key is corrupted" spectre which has been invoked as justification for choosing E&M. (Any paper whose results depend on implementations being bug-free needs a very careful read-over before it can be considered to apply to real software.) It also considers possibilities such as a MAC leaking information about the data it is applied to. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri May 9 11:24:17 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B365D1A00B4 for ; Fri, 9 May 2014 11:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq5djQUqtpq4 for ; Fri, 9 May 2014 11:24:14 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0FC1A02EF for ; Fri, 9 May 2014 11:24:14 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 3D4BC14A2A4; Fri, 9 May 2014 18:24:07 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9B18A14A29D for ; Fri, 9 May 2014 18:24:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id qzl2b73VPA8p for ; Fri, 9 May 2014 18:24:04 +0000 (UTC) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by mail.netbsd.org (Postfix) with ESMTP id C994914A194 for ; Fri, 9 May 2014 18:24:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 96C0FBE75 for ; Fri, 9 May 2014 19:23:58 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkoJMzR+nxOb for ; Fri, 9 May 2014 19:23:57 +0100 (IST) Received: from [172.17.73.26] (unknown [187.185.71.234]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CEA85BE8E for ; Fri, 9 May 2014 19:23:53 +0100 (IST) Message-ID: <536D1D38.8030808@cs.tcd.ie> Date: Fri, 09 May 2014 19:23:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Fwd: [IANA #758943] early allocation request for draft-moonesamy-sshfp-ed25519 References: In-Reply-To: X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list FYI, that code point has been allocated. Will be permanent once the RFC thing's done. Cheers, S. -------- Original Message -------- Subject: [IANA #758943] early allocation request for draft-moonesamy-sshfp-ed25519 Date: Fri, 9 May 2014 18:21:49 +0000 From: Amanda Baber via RT Reply-To: iana-prot-param@iana.org To: sm+ietf@elandsys.com, stephen.farrell@cs.tcd.ie Hi all, IANA has made the following assignment in the SSHFP RR Types for public key algorithms registry: 4 ED25519 (TEMPORARY - expires 2015-05-09) [draft-moonesamy-sshfp-ed25519] Please see http://www.iana.org/assignments/dns-sshfp-rr-parameters Best regards, Amanda Baber IANA Request Specialist ICANN From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri May 9 23:37:40 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F751A01AD for ; Fri, 9 May 2014 23:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhULCetqXGxg for ; Fri, 9 May 2014 23:37:38 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 75AF61A01AC for ; Fri, 9 May 2014 23:37:38 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 75DD114A14E; Sat, 10 May 2014 06:37:31 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4BFB714A142 for ; Sat, 10 May 2014 06:37:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id hGelN1SUy1ZF for ; Sat, 10 May 2014 06:37:27 +0000 (UTC) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by mail.netbsd.org (Postfix) with ESMTP id 64C0514A13D for ; Sat, 10 May 2014 06:37:27 +0000 (UTC) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id CAA20024; Sat, 10 May 2014 02:37:14 -0400 (EDT) Date: Sat, 10 May 2014 02:37:14 -0400 (EDT) From: Mouse Message-Id: <201405100637.CAA20024@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Sat, 10 May 2014 02:17:20 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: Albrecht/Paterson/Watson's attack In-Reply-To: References: <201405051939.PAA04252@Chip.Rodents-Montreal.ORG> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list [me] >> http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf [denis] > Our implementation in Bitvise SSH Server (versions of the last > several years that use our FlowSsh library) makes this class of > attack difficult by: [turning corrupt packet lengths into random > valid packet lengths] I've now implemented this defense in moussh. I don't quite do it as described above, because, if done that simply, there is a (small) chance the MAC will pass and feed corrupted data into the session. When generating a random valid packet length, I also switch the connection to using a dummy MAC algorithm which is basically just like the "none" algorithm except that checks always fail (for "none" they always succeed). Thus, when/if the randomized packet length is exhausted, it will exhibit the behaviour corresponding to a MAC failure with probability 1, rather than 1-(2^-160) (or whatever, depending on the MAC in use). [me] >> make it hard to identify packet boundaries by, whenever the >> connection would otherwise go idle, generating an IGNORE packet and >> sending only part of it, holding the rest until something more is >> available to be sent on that connection. > I think that's a good idea in general, also to make traffic analysis > a bit more difficult. moussh does not yet include this defense; I found it remarkably difficult to do. I will need to think about how to implement this. It may call for improving the APIs to my crypto libraries, since it's hard to do this without either (a) generating a lot of unnecessary IGNOREs or (b) having support for encrypting something and then rolling back, a way to encrypt the IGNORE and then, if it turns out it doesn't get written, reset the crypto's state to pretend it wasn't encrypted after all. (Doing it in another write() would be easy, but risks introducing a TCP packet boundary at the BPP packet boundary whose concealment is the whole point of this. TCP doesn't promise that write() boundaries will produce TCP segment boundaries, but it actually does so relatively often anyway.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat May 10 00:10:49 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733901A01B6 for ; Sat, 10 May 2014 00:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5XLgPBQokwu for ; Sat, 10 May 2014 00:10:47 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDCC1A01A7 for ; Sat, 10 May 2014 00:10:47 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 3BE3D14A34A; Sat, 10 May 2014 07:10:35 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 3FA9214A340 for ; Sat, 10 May 2014 07:10:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 495na9aBW3YC for ; Sat, 10 May 2014 07:10:30 +0000 (UTC) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 3F23414A312 for ; Sat, 10 May 2014 07:10:28 +0000 (UTC) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s4A7APdi009714; Sat, 10 May 2014 09:10:25 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s4A7AOuB009713; Sat, 10 May 2014 09:10:24 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Mouse Cc: ietf-ssh@netbsd.org Subject: Re: Albrecht/Paterson/Watson's attack References: <201405051939.PAA04252@Chip.Rodents-Montreal.ORG> <201405100637.CAA20024@Chip.Rodents-Montreal.ORG> Date: Sat, 10 May 2014 09:10:24 +0200 In-Reply-To: <201405100637.CAA20024@Chip.Rodents-Montreal.ORG> (mouse@rodents-montreal.org's message of "Sat, 10 May 2014 02:37:14 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Mouse writes: > moussh does not yet include this defense; I found it remarkably > difficult to do. I have some code to do this (not yet in any relased version, though, I don't get much time for lsh hacking these days). I have a "push" flag for the functions to encrypt and send of an ssh package. Packets without this flag is buffered. When the buffered data exceeds a reasonable packet size, I send the packet out with no extra ignore message. If the push flag is set, the packet is sent regardless of the amount of buffered data, and an extra ignore message is appended to the buffer. See http://git.lysator.liu.se/lsh/lsh/blobs/master/src/transport_write.c Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat May 10 03:01:57 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F111A0209 for ; Sat, 10 May 2014 03:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88-bmoDSQQUK for ; Sat, 10 May 2014 03:01:52 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id E07601A020E for ; Sat, 10 May 2014 03:01:46 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 61A6514A314; Sat, 10 May 2014 10:01:41 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 3D62014A2FB for ; Sat, 10 May 2014 10:01:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (1024-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id iL7XIL-POxh1 for ; Sat, 10 May 2014 10:01:38 +0000 (UTC) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 1469614A2E3 for ; Sat, 10 May 2014 10:01:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1399716098; x=1431252098; h=date:message-id:from:to:subject:in-reply-to; bh=TOa+3PGFgYMldEB5EXaxTHj8OBdSbdcCbQZMq3yuQv0=; b=PVU1ZVnCtmPwfnbywNh/yjQJv1/YuVaHoNpvYZ7bGOCsoslvnRg3PywA kJBXI+eUfonhZutx7LOAMLLB3GDyHu9YgS/JVI9kCrZfO3qD4GCxWxjQH Mxi3sUjHdKo9oWStuJCza8fLKfIJ/vhbW2/pYZtubsVYW43dyAP0gE2jA I=; X-IronPort-AV: E=Sophos;i="4.97,1023,1389697200"; d="scan'208";a="251437434" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.34.40 - Outgoing - Outgoing Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 May 2014 22:01:33 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.72) (envelope-from ) id 1Wj45z-0007WQ-Vp; Sat, 10 May 2014 22:01:31 +1200 Date: Sat, 10 May 2014 22:01:31 +1200 Message-Id: From: Peter Gutmann To: ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG Subject: Re: Albrecht/Paterson/Watson's attack In-Reply-To: <201405082144.RAA05625@Chip.Rodents-Montreal.ORG> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Mouse writes: >> If you still need to run crypto ops before you can verify the MAC >> you're not actually doing EtM, or at least not getting the security >> benefits that it provides. > >What benefits _does_ it provide? Why do they outweigh exposing packet sizes? It eliminates about a decade's worth of assorted oracle attacks on encryption algorithms, implementations, packet-handling code, and so on. The "not exposing packet sizes" is rather overrated in any case, unless you go to extraordinary lengths in your implementation all an attacker has to do is look at the TCP traffic to see where one packet stops and the next one starts. In any case apart from sensitive packets like ones containing password info (e.g. the userauth messages), which one would hope are padded to a fixed size, what real, actual benefit (not gedanken-experiment hypothesis) does an attacker gain from knowing the packet length? My guess is that most (all?) SSH implementations have been exposing packet lengths (at the TCP level) for more than a decade without anyone being able to exploit it. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat May 10 04:35:20 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839D81A0217 for ; Sat, 10 May 2014 04:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHHsZRGny49m for ; Sat, 10 May 2014 04:35:17 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id E822E1A01AB for ; Sat, 10 May 2014 04:35:17 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 6D76B14A35E; Sat, 10 May 2014 11:35:05 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 75F4D14A35D for ; Sat, 10 May 2014 11:35:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (1024-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id pdljATZi8MLp for ; Sat, 10 May 2014 11:35:02 +0000 (UTC) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 60F1914A35C for ; Sat, 10 May 2014 11:35:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1399721702; x=1431257702; h=date:message-id:from:to:subject:cc:in-reply-to; bh=1USSLiKrdIUdKniztVzIMXjT5fBxXwydzyUUmx287Zk=; b=l0uBNKTw+5hsYGINwX3+9hhhSTCtRO9JSHHtDw9ZH9/PmLrmUgSSgfnr 1y8lbGNUVGAIs0ciMdGdrhAl2peCM5pPWCtB5Vi8nLS9BBlMZRW1t+p9f +EDbHe2P2/Q55YXZhpTtPcygma7XE4wnkCPtNEtJ2Q5UbgtYCy8Txkfnp g=; X-IronPort-AV: E=Sophos;i="4.97,1023,1389697200"; d="scan'208";a="251437701" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.34.40 - Outgoing - Outgoing Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 May 2014 22:06:11 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.72) (envelope-from ) id 1Wj4AT-0007YU-MR; Sat, 10 May 2014 22:06:09 +1200 Date: Sat, 10 May 2014 22:06:09 +1200 Message-Id: From: Peter Gutmann To: anakin@pobox.com, pgut001@cs.auckland.ac.nz Subject: Re: Albrecht/Paterson/Watson's attack Cc: ietf-ssh@netbsd.org In-Reply-To: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Simon Tatham writes: >The MAC would apply to the ciphertext, and the length would be the full >length of the ciphertext (or perhaps ciphertext+MAC) in clear. That's what I'd like to see too. My code, and presumably everyone else's as well, currently contains a large pile of ad-hockery to kludge around all the different side-channel attacks you have to worry about with the current way packet data is handled. Being able to do: read length; read that many bytes; run MAC and accept/reject; would cut out all of this. The only thing you need to worry about is not using memcmp() for the MAC check. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat May 10 10:09:13 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1624C1A0278 for ; Sat, 10 May 2014 10:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsRHWdazmm1x for ; Sat, 10 May 2014 10:09:11 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id D86011A0271 for ; Sat, 10 May 2014 10:09:11 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 94C9B14A340; Sat, 10 May 2014 17:09:04 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id F294B14A331 for ; Sat, 10 May 2014 17:09:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id vKzR9VgxuemV for ; Sat, 10 May 2014 17:09:00 +0000 (UTC) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by mail.netbsd.org (Postfix) with ESMTP id D221D14A327 for ; Sat, 10 May 2014 17:08:59 +0000 (UTC) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id NAA08634; Sat, 10 May 2014 13:08:59 -0400 (EDT) Date: Sat, 10 May 2014 13:08:59 -0400 (EDT) From: Mouse Message-Id: <201405101708.NAA08634@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Sat, 10 May 2014 12:47:10 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: Albrecht/Paterson/Watson's attack In-Reply-To: References: <201405051939.PAA04252@Chip.Rodents-Montreal.ORG> <201405100637.CAA20024@Chip.Rodents-Montreal.ORG> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> moussh does not yet include this defense [partial IGNORE packets]; I >> found it remarkably difficult to do. > I have some code to do this [...]. I have a "push" flag for the > functions to encrypt and send of an ssh package. Packets without > this flag is buffered. When the buffered data exceeds a reasonable > packet size, I send the packet out with no extra ignore message. > If the push flag is set, the packet is sent regardless of the amount > of buffered data, and an extra ignore message is appended to the > buffer. Vastly different internal architecture. My code sends packets by encrypting them and appending to an output queue. There's a separate work procedure (a little like a thread without a stack) that writes from the output queue. In this paradigm, the connection going idle amounts to the output queue draining completely. But, in order for something to be written in the same writev() as the output queue, it has to be ready to be written. But that means running it through the crypto, consuming key material. Since I have no way of telling how much is writable at any given moment (even postulating a call that asks that could fail because the answer could change between query and writev), I can't tell whether the writev() will drain the queue (and I thus want a partial IGNORE packet there) or not (in which case I don't). So I'd have to always append it - but then, to avoid a zillion unnecesasry IGNOREs, I'd need the ability to retract it if no part of it actually gets written. That's where it gets interesting. I could extend the output queue to store a possible IGNORE separately, but that wouldn't help because it has to be encrypted in sequence with the packets on either side of it, which would change (potentially) each time around. I could store it in the clear, but I have no way to tell whether I need to encrypt it; there's no way for writev() to tell me whether it wants more data in a way that lets me compute before providing it. Of course, the output queue draining in userland is not the same as the TCP output queue draining. I'd rather drive it off the latter, but there's no easy way to do that; for most purposes, the userland queue draining is a good enough approximation. I might be able to add something like your `push' flag, but it's not clear to me when I should set it. It sounds to me as though your paradigm will insert IGNOREs at certain points in the output stream even if the connectino _isn't_ going idle - correct? I need to think about this more. I may need a redesign, or I may come up with a clean way to do the crypto rollback, or who knows.... /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat May 10 10:37:37 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752141A0086 for ; Sat, 10 May 2014 10:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wn81o4buVgY1 for ; Sat, 10 May 2014 10:37:35 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id CD78E1A0063 for ; Sat, 10 May 2014 10:37:35 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 4162514A18E; Sat, 10 May 2014 17:37:29 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 3069014A34C for ; Sat, 10 May 2014 17:37:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id WX4z4ddjKvi4 for ; Sat, 10 May 2014 17:37:22 +0000 (UTC) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by mail.netbsd.org (Postfix) with ESMTP id 251E814A341 for ; Sat, 10 May 2014 17:37:22 +0000 (UTC) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id NAA09389; Sat, 10 May 2014 13:37:21 -0400 (EDT) Date: Sat, 10 May 2014 13:37:21 -0400 (EDT) From: Mouse Message-Id: <201405101737.NAA09389@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Sat, 10 May 2014 13:09:08 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Albrecht/Paterson/Watson's attack In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> What benefits _does_ [EtM] provide? Why do they outweigh exposing >> packet sizes? > It eliminates about a decade's worth of assorted oracle attacks on > encryption algorithms, implementations, packet-handling code, and so > on. ...replacing them with something with an unknown set of issues, because it hasn't had a decade-plus of burning in. > The "not exposing packet sizes" is rather overrated in any case, Perhaps. I'm not convinced either way on that. > unless you go to extraordinary lengths in your implementation all an > attacker has to do is look at the TCP traffic to see where one packet > stops and the next one starts. Even to the extent that the TCP in use reflects write() boundaries as segment boundaries (which in my limited experience is mostly true under low load with small writes and usually not under high load or with large writes), that will give the attacker only some packet boundaries. That is, segment boundaries will be packet boundaries, but packet boundaries may not be segment boundaries. I haven't seen an analysis of the risks of exposing such metadata. I'm not competent to do that myself; until someone does do such an analysis, I'm not going to take it on myself to decide that the exposure is ignorable. > In any case apart from sensitive packets like ones containing > password info (e.g. the userauth messages), which one would hope are > padded to a fixed size, They are not, in general - see section 8 of 4252; it does not specify, nor even recommend, any padding. Since there is no easy way to set a maximum on password length on a remote system, it's hard (even aside from possible internal architecture issues) to pd them to a fixed size. Implementations certainly could pad if they felt like it; have you looked to see whether any of the ones you have access to do? moussh does not pad password-carrying packets except as required by section 6 of 4253 (which applies to all packets, not just password-carrying ones). Indeed, I would be inclined to worry that padding password packets specially might make them more identifiable on the wire. > what real, actual benefit (not gedanken-experiment hypothesis) does > an attacker gain from knowing the packet length? I don't know; I'm not an attacker. I do know that I'm not about to meddle with a crypto protocol without reasonable assurance that it won't cause trouble, and "a dilettante cryptographer [me] couldn't describe an exploitable problem with the new protocol offhand" is not good enough assurance. > My guess is that most (all?) SSH implementations have been exposing > packet lengths (at the TCP level) for more than a decade without > anyone being able to exploit it. Er, not quite. "without anyone exploiting it" != "without anyone being able to exploit it". (Furthermore, "without anyone exploiting it" != "without your hearing of anyone exploiting it", but since I don't know how well-placed you might be to hear of such things, I'm willing to plead nolo contendere on that point.) Also, as I outlined above, I'm far from convinced that exposing TCP packet boundaries is equivalent to exposing packet lengths. Also, "more than a decade"? The SSH RFCs are dated January 2006, so presumably you are including SSHv1 - what are the differences at these levels of its protocol? I've never seen documentation on its protocol other than the code, and I've never been motivated enough to reverse-engineer the protocol documentation from the code. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat May 10 12:10:15 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94FD1A0228 for ; Sat, 10 May 2014 12:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfhT_GCUzuKk for ; Sat, 10 May 2014 12:10:14 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 258C81A0099 for ; Sat, 10 May 2014 12:10:14 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 8AB3A14A356; Sat, 10 May 2014 19:10:06 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 067F114A353 for ; Sat, 10 May 2014 19:10:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 7bldq9MzRvbT for ; Sat, 10 May 2014 19:10:03 +0000 (UTC) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 0A97914A351 for ; Sat, 10 May 2014 19:10:01 +0000 (UTC) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s4AJ9xM0023087; Sat, 10 May 2014 21:09:59 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s4AJ9wWo023086; Sat, 10 May 2014 21:09:58 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Mouse Cc: ietf-ssh@netbsd.org Subject: Re: Albrecht/Paterson/Watson's attack References: <201405051939.PAA04252@Chip.Rodents-Montreal.ORG> <201405100637.CAA20024@Chip.Rodents-Montreal.ORG> <201405101708.NAA08634@Chip.Rodents-Montreal.ORG> Date: Sat, 10 May 2014 21:09:58 +0200 In-Reply-To: <201405101708.NAA08634@Chip.Rodents-Montreal.ORG> (mouse@rodents-montreal.org's message of "Sat, 10 May 2014 13:08:59 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Mouse writes: > Vastly different internal architecture. My code sends packets by > encrypting them and appending to an output queue. If you do it similarly to what I do, you'd need to add a (short) queue of unencrypted packets before the output buffer. I think that's more sane than a "crypto rollback". > I might be able to add something like your `push' flag, but it's not > clear to me when I should set it. It sounds to me as though your > paradigm will insert IGNOREs at certain points in the output stream > even if the connectino _isn't_ going idle - correct? I might add some unnecessary ignores, but the intention is not to never add them if output queue already is larger than a tcp segment. I think the push flag will be set for most messages, except when you know that additional messages will be generated shortly. E.g., when reading data for a tcp forward, if you check with FIONREAD that there's more data coming (and there's more window space), you can pass a false push flag for the corresponding SSH_MSG_CHANNEL_DATA message. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon May 12 07:28:03 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57F41A0727 for ; Mon, 12 May 2014 07:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tZMAHjIb5mr for ; Mon, 12 May 2014 07:28:00 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id C2E621A0713 for ; Mon, 12 May 2014 07:28:00 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id DB27B14A1C9; Mon, 12 May 2014 14:27:51 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A289F14A1AB for ; Mon, 12 May 2014 14:27:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id XTFTnW53OWv0 for ; Mon, 12 May 2014 14:27:49 +0000 (UTC) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by mail.netbsd.org (Postfix) with ESMTP id DA7FB14A1A4 for ; Mon, 12 May 2014 14:27:48 +0000 (UTC) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id KAA25904; Mon, 12 May 2014 10:08:06 -0400 (EDT) Date: Mon, 12 May 2014 10:08:06 -0400 (EDT) From: Mouse Message-Id: <201405121408.KAA25904@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Sun, 11 May 2014 22:11:26 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: Albrecht/Paterson/Watson's attack In-Reply-To: References: <201405051939.PAA04252@Chip.Rodents-Montreal.ORG> <201405100637.CAA20024@Chip.Rodents-Montreal.ORG> <201405101708.NAA08634@Chip.Rodents-Montreal.ORG> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> Vastly different internal architecture. My code sends packets by >> encrypting them and appending to an output queue. > If you do it similarly to what I do, you'd need to add a (short) > queue of unencrypted packets before the output buffer. I think > that's more sane than a "crypto rollback". I don't see how that would help. I'd still need to either encrypt the possibly-desired IGNORE or do the write without it and risk a BPP-level packet boundary appearing as a TCP segment boundary via being a write boundary. > I might add some unnecessary ignores, but the intention is not to > never add them if output queue already is larger than a tcp segment. How do you tell how large TCP segments are? > I think the push flag will be set for most messages, except when you > know that additional messages will be generated shortly. Sounds to me as though you'll end up sprinkling IGNOREs all through most traffic. That's one of the effects I'd like to avoid. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon May 12 08:02:28 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9371A0721 for ; Mon, 12 May 2014 08:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzOUR56rG-lW for ; Mon, 12 May 2014 08:02:26 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 290D81A0712 for ; Mon, 12 May 2014 08:02:26 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 130E914A26E; Mon, 12 May 2014 15:02:18 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id EB42F14A26A for ; Mon, 12 May 2014 15:02:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id s-iRS_YORf6g for ; Mon, 12 May 2014 15:02:13 +0000 (UTC) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id B62C314A25F for ; Mon, 12 May 2014 15:02:11 +0000 (UTC) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s4CF281c028689; Mon, 12 May 2014 17:02:08 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s4CF27rJ028685; Mon, 12 May 2014 17:02:07 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Mouse Cc: ietf-ssh@netbsd.org Subject: Re: Albrecht/Paterson/Watson's attack References: <201405051939.PAA04252@Chip.Rodents-Montreal.ORG> <201405100637.CAA20024@Chip.Rodents-Montreal.ORG> <201405101708.NAA08634@Chip.Rodents-Montreal.ORG> <201405121408.KAA25904@Chip.Rodents-Montreal.ORG> Date: Mon, 12 May 2014 17:02:07 +0200 In-Reply-To: <201405121408.KAA25904@Chip.Rodents-Montreal.ORG> (mouse@rodents-montreal.org's message of "Mon, 12 May 2014 10:08:06 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Mouse writes: >> If you do it similarly to what I do, you'd need to add a (short) >> queue of unencrypted packets before the output buffer. I think >> that's more sane than a "crypto rollback". > > I don't see how that would help. I'd still need to either encrypt the > possibly-desired IGNORE or do the write without it and risk a BPP-level > packet boundary appearing as a TCP segment boundary via being a write > boundary. The idea is that you collect a queue of cleartext packets. Then one of two events can get you to encrypt messages, filling the output buffer with encrypted data. 1. When you have collected enough data to generate a tcp packet of the desired size. Encrypt messages one at a time until you have enough data in the output buffer. Do a single write of the desired size. 2. Otherwise, if you get a message with the push flag set, generate a large enough ignore message, then go to step 1. My code appends the ignore message. >From this discussion I've understood that it would in some ways be better to insert the ignore message somewhere *before* the message needing push. E.g, SSH_MSG_IGNORE | SSH_MSG_USERAUTH provides better hiding than SSH_MSG_USERAUTH | SSH_MSG_IGNORE, but I haven't digested the implications of that. > How do you tell how large TCP segments are? I don't, I'm just thinking that if all my writes are of a fixed size, say 1300 bytes, the tcp stack can split that into segments anyway it likes, segment boundaries ought to be independent of the ssh message boundaries regardless. And then in practice, I don't use a *single* large packet size, but a small number of allowed packet sizes, in order to not bloat an interactive terminal session too much, where I typically collect only a few keystrokes per message (using VMIN = 3, VTIME = 2 for the tty). > Sounds to me as though you'll end up sprinkling IGNOREs all through > most traffic. That's one of the effects I'd like to avoid. They will be omitted whenever the output buffer starts to fill up. But otherwise, the intention is that a typical tcp segment will consist of | ...end of SSH_MSG_IGNORE | SSH_MSG_other | start of SSH_MSG_IGNORE... | Regards, /Niels > /~\ The ASCII Mouse > \ / Ribbon Campaign > X Against HTML mouse@rodents-montreal.org > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue May 20 23:20:39 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC741A0484 for ; Tue, 20 May 2014 23:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4102LgWfeaZ3 for ; Tue, 20 May 2014 23:20:37 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDF611A027C for ; Tue, 20 May 2014 23:20:37 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id EB26014A4DD; Wed, 21 May 2014 06:20:35 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 23CEC14A4D9; Wed, 21 May 2014 06:20:35 +0000 (UTC) Date: Wed, 21 May 2014 06:20:35 +0000 From: "S.P.Zeidler" To: ietf-ssh@NetBSD.org Subject: should I let conference CfP etc onto ietf-ssh? Message-ID: <20140521062035.GA11572@homeworld.netbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi folks, I'm your current list caretaker. Should I let conference Call for Papers and similar invitations through if the conference looks halfway legitimate and related to ssh? regards, spz From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed May 21 09:43:25 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F36D1A073F for ; Wed, 21 May 2014 09:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.551 X-Spam-Level: X-Spam-Status: No, score=-4.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56svbgUA6Bte for ; Wed, 21 May 2014 09:43:24 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A8C1A06B3 for ; Wed, 21 May 2014 09:43:24 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 09C7014A5C2; Wed, 21 May 2014 16:43:21 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5D3BC14A5C0; Wed, 21 May 2014 16:43:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id uwv-_FeZQBDD; Wed, 21 May 2014 16:43:17 +0000 (UTC) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1ln0183.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e00::183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 8561714A5BF; Wed, 21 May 2014 16:43:16 +0000 (UTC) Received: from AMXPRD0111HT003.eurprd01.prod.exchangelabs.com (157.56.250.117) by AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) with Microsoft SMTP Server (TLS) id 15.0.949.11; Wed, 21 May 2014 16:43:11 +0000 Message-ID: <019801cf7513$62ca7ea0$4001a8c0@gateway.2wire.net> From: t.petch To: S.P.Zeidler , References: <20140521062035.GA11572@homeworld.netbsd.org> Subject: Re: should I let conference CfP etc onto ietf-ssh? Date: Wed, 21 May 2014 17:34:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.250.117] X-ClientProxiedBy: AMSPR07CA009.eurprd07.prod.outlook.com (10.242.77.177) To AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) X-Forefront-PRVS: 0218A015FA X-Forefront-Antispam-Report: SFV:NSPM;SFS:(6009001)(428001)(51704005)(30513003)(199002)(189002)(13464003)(377454003)(87976001)(81342001)(62966002)(23756003)(81542001)(89996001)(44736004)(86362001)(4396001)(92726001)(85852003)(83072002)(93916002)(88136002)(21056001)(19580405001)(83322001)(31966008)(19580395003)(101416001)(42186004)(74662001)(61296002)(74502001)(92566001)(81816999)(44716002)(87286001)(79102001)(50986999)(50466002)(81686999)(102836001)(99396002)(47776003)(64706001)(80022001)(76482001)(33646001)(14496001)(84392001)(77156001)(66066001)(20776003)(62236002)(76176999)(50226001)(46102001)(77982001)(74416001)(7726001);DIR:OUT;SFP:;SCL:1;SRVR:AMXPR07MB053;H:AMXPRD0111HT003.eurprd01.prod.exchangelabs.com;FPR:;MLV:nov;PTR:InfoNoRecords;A:0;MX:1;LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Yes. They may be of interest and, even if they are not, they provide a useful heartbeat protocol for a list that is often quiet and for which, almost uniquely, I do not ever get a reminder of my subscription. Tom Petch ----- Original Message ----- From: "S.P.Zeidler" To: Sent: Wednesday, May 21, 2014 7:20 AM Subject: should I let conference CfP etc onto ietf-ssh? > Hi folks, > > I'm your current list caretaker. Should I let conference Call for Papers > and similar invitations through if the conference looks halfway legitimate > and related to ssh? > > regards, > spz > From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed May 21 10:02:12 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB671A0875 for ; Wed, 21 May 2014 10:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.441 X-Spam-Level: X-Spam-Status: No, score=-4.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, GB_I_INVITATION=-2, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtAjSGhqx7ct for ; Wed, 21 May 2014 10:02:11 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CE321A085D for ; Wed, 21 May 2014 10:02:11 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 7869614A4EB; Wed, 21 May 2014 17:02:08 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7FE9D14A4DD; Wed, 21 May 2014 17:02:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=cibH+HiX; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=hNKQf999 Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id v-AIyiT0UWW9; Wed, 21 May 2014 17:02:06 +0000 (UTC) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by mail.netbsd.org (Postfix) with ESMTP id DB2E314A449; Wed, 21 May 2014 17:02:04 +0000 (UTC) Received: from SUBMAN.elandsys.com ([197.224.153.171]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s4LH1qNt003908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2014 10:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1400691724; bh=CKLyQPrLoKjgN2t5j8dhxvR1GoMmoRZrZ+4/GKv2Yhg=; h=Date:To:From:Subject:In-Reply-To:References; b=cibH+HiX7FNyA5IHwZ7tbdFIr2OqQLYzur6MPIG50bNVKdwYRmcfArHlcFgWdHiwu XR4a86jzeUQwB0A05svxgeOMpK/MeEqvVWCzqShCw4/rdeu/wIsxqivgHoYnxSiUl/ sc62aJ4K8kZo/kPqdgxLKRc0PQeixCCWNY0BDMPE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1400691724; i=@elandsys.com; bh=CKLyQPrLoKjgN2t5j8dhxvR1GoMmoRZrZ+4/GKv2Yhg=; h=Date:To:From:Subject:In-Reply-To:References; b=hNKQf999wRQhPT6R4PhJW6AAAJBG1PIdlwKP3poiqaeCO7ZlkoLZL6eLSbNdpZEHY GZk6Kb0QBIgkMxJnZK5K5UIH5aCWt46/G3mi6Zgakifbwlcebfw5A2VltDI6SeRSQz YhXRMlbROPp8eAjN75tKt95ETlz1kc4z/HNrVWO4= Message-Id: <6.2.5.6.2.20140521094743.0bbdf9f0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 21 May 2014 09:57:51 -0700 To: "S.P.Zeidler" , ietf-ssh@NetBSD.org From: S Moonesamy Subject: Re: should I let conference CfP etc onto ietf-ssh? In-Reply-To: <20140521062035.GA11572@homeworld.netbsd.org> References: <20140521062035.GA11572@homeworld.netbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list At 23:20 20-05-2014, S.P.Zeidler wrote: >I'm your current list caretaker. Should I let conference Call for Papers >and similar invitations through if the conference looks halfway legitimate >and related to ssh? I usually avoid conference Call for Papers as some random person would send them to every mailing list he/she can find. Some of these Call for Papers look suspicious. I would leave it to the list moderator to decide what to let through. Regards, S. Moonesamy