Re: [Rift] RIFT fingerprint coverage

Antoni Przygienda <prz@juniper.net> Sun, 21 July 2019 14:22 UTC

Return-Path: <prz@juniper.net>
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50A9120176 for <rift@ietfa.amsl.com>; Sun, 21 Jul 2019 07:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 cPTbw6mDHg_m for <rift@ietfa.amsl.com>; Sun, 21 Jul 2019 07:22:41 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B911201D5 for <rift@ietf.org>; Sun, 21 Jul 2019 07:22:40 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6LEK3Zp027120; Sun, 21 Jul 2019 07:22:39 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=Z6yjKFDo2sPJhv33Eo2mdgG0YhtlJxHiibQbE6W6Ls0=; b=ok3Dl4ko5PZQmEfg9V9pZthtnFr+QvlE1Rlafyxy5tQ3RDLf2uXX9ZwwwoUdrScFx1lU tshpLPA93M4xWL1q03hQOH1nAK0aFF/rFsYpKMsFU+SIzySSntydrLPtpjYG5LLrggk6 7bAHdqkW7JPCo5rQ5yCn2uziGLvYFPnK+Nt8c/uFnuh8I3gL6bfytEwpzdVBDT9E0buo dBCpcXFi6N/kXWqG8oXYAXLDCjGyZhGoQXn+sqXXQOI65rzIROf0ofVuxibMDevc1SxD wtem3N3Afa4FcBBNMEuOhMNya20QfMZECCgIk7XFU+eoEHUC3M594EWP5N0eiy38mNg/ Lg==
Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp2053.outbound.protection.outlook.com [104.47.40.53]) by mx0b-00273201.pphosted.com with ESMTP id 2tux6q1dpv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 21 Jul 2019 07:22:39 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WSZOnGGwSyc/37JL9RJe/d7IZ7NOGccK1LmKYHL0DvFLRsUDvjL7MLRg4SHaZEz/CGtcVNeuOMQC4sl1mSzlGNDZ7fEWTTwvRE7yGZPwAvBkON0Dy9RPtSeCDPyxh2vOsKdKzQ7I+V17AUB7X6I6xH7rW9jfjlxd0olBdxu82t4tUBAm6RcCSOEj41E8ePVMEdKIyCxLOnhE5EdL7TM4me+byDm4CtzrEUo+V0Tb4f1Hpxjfw1Dg8wAqpbt9KB/a7tUi9qp9LXEc+u/dWreKbAygban4KKZLrPD/KeiB0ko4TNDJQxzVbYOzbSIXhJ4JiQVGSxQEhAZzpad47KmT3w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z6yjKFDo2sPJhv33Eo2mdgG0YhtlJxHiibQbE6W6Ls0=; b=D4uznfp92b5u+wL9KliJK60No1Ps7Ye6zlhkFRmAGx/g+tn61eci/4v8hD9t/8Fr66CZJV+TYez2/nb8zQ9r2WSObYcNrH7+A1USig8Fqw2cBKwYrKpz8yxYFtSjyFzC+6iu8Isv7IK+NGv2E6oXxgnRTsHaL7N/iACt7XP3DNpgOCbaWCVu9FtEVcCwIS0DCbwN7Wck+LbdTJqNVcAJ2TUAhCmgrGEXH5uPSi2Xub+sF5zbWIAgZpDZG2M61HAShb6fmmC7D2rsX9eitjuQahIPeVHOJXojcpI+FfOmpHC8HHgBki1uRh2+wjlclMnnoGcGaNgwfWVFkOwgz7kJVw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=juniper.net;dmarc=pass action=none header.from=juniper.net;dkim=pass header.d=juniper.net;arc=none
Received: from MWHPR05MB3279.namprd05.prod.outlook.com (10.173.229.20) by MWHPR05MB3087.namprd05.prod.outlook.com (10.173.235.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.8; Sun, 21 Jul 2019 14:22:35 +0000
Received: from MWHPR05MB3279.namprd05.prod.outlook.com ([fe80::37:4711:1630:3ff0]) by MWHPR05MB3279.namprd05.prod.outlook.com ([fe80::37:4711:1630:3ff0%10]) with mapi id 15.20.2115.005; Sun, 21 Jul 2019 14:22:35 +0000
From: Antoni Przygienda <prz@juniper.net>
To: Bruno Rijsman <brunorijsman@gmail.com>, Tony Przygienda <tonysietf@gmail.com>
CC: "rift@ietf.org" <rift@ietf.org>
Thread-Topic: RIFT fingerprint coverage
Thread-Index: AQHVP6eYezbRLceY0U6gavGzd3xvM6bU4fWAgAA7aKE=
Date: Sun, 21 Jul 2019 14:22:35 +0000
Message-ID: <MWHPR05MB32795B106572C9AD42A30DCFACC50@MWHPR05MB3279.namprd05.prod.outlook.com>
References: <CF366357-79EA-4395-9024-09A371795695@gmail.com>, <F165CA6D-3537-4310-8453-77B069F69414@gmail.com>
In-Reply-To: <F165CA6D-3537-4310-8453-77B069F69414@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6b77a8f7-5c8f-44d8-63d1-08d70de6e074
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:MWHPR05MB3087;
x-ms-traffictypediagnostic: MWHPR05MB3087:
x-microsoft-antispam-prvs: <MWHPR05MB30878EBAEBCC7393952CD7A5ACC50@MWHPR05MB3087.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0105DAA385
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(136003)(396003)(366004)(376002)(346002)(189003)(199004)(53546011)(8676002)(66066001)(7696005)(8936002)(76176011)(81166006)(6506007)(52536014)(26005)(486006)(66556008)(74316002)(7116003)(236005)(102836004)(14444005)(14454004)(186003)(2906002)(316002)(66446008)(64756008)(66946007)(66476007)(6116002)(110136005)(76116006)(256004)(6436002)(3846002)(54896002)(11346002)(446003)(53936002)(71200400001)(81156014)(25786009)(476003)(9686003)(6246003)(229853002)(5660300002)(99286004)(7736002)(478600001)(19627405001)(105004)(55016002)(4326008)(86362001)(71190400001)(3480700005)(33656002)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3087; H:MWHPR05MB3279.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: arFnJLa/D1tSfN5A5mx/rbGG01JeNiBYrn8a5QYBUyBLb2B5nGzi1S2BAm9XEAgfJ+DvdIgXEgrYaulPABsi5gga/oGS5hIQPqgFJvginBp/u7ndhkehWhIjOfi7Xn2DFFhcHdT7JO/haFWVM6PU2vD/nm0x8c+ttt0LdcBeg9ezeY1JufLz3+P9xd5q77wyjqQNQnRXGkh5kN00THHOkyMoEKD3fZOfAOLU5EOhKUkRCnUAmGfA6LMIGL7ZMdXAxRpUj/PfeSRx12cyHK7gX/rNd+ERijd3Dgqv6dITeUH9Hem+ueK57pimu+Vbnw0zwX74rz5mQU0OT35tLaLQbsD3PHKlg+EDRPyC5R3qFkhtjAZgeAyCNprYXg4Tur+XrfxFdOJZbYPGk8opqAthZxS8srpDYsGmTkfPDGBPDU4=
Content-Type: multipart/alternative; boundary="_000_MWHPR05MB32795B106572C9AD42A30DCFACC50MWHPR05MB3279namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 6b77a8f7-5c8f-44d8-63d1-08d70de6e074
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2019 14:22:35.4378 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: prz@juniper.net
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3087
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-21_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907210172
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/tIgr-4gzPdwzLIGNaR6Py8A2bOs>
Subject: Re: [Rift] RIFT fingerprint coverage
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Routing in Fat Trees <rift.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rift>, <mailto:rift-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rift/>
List-Post: <mailto:rift@ietf.org>
List-Help: <mailto:rift-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rift>, <mailto:rift-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jul 2019 14:22:51 -0000

  1.  I don't like the change of inner security key name, we may one day protect something else than TIEs with it and on top it makes the naming less intuitive, the outer and inner works really well IMO
  2.  first, you can't extend the protection the way you like unless we have a complicated procedure where you protec with fingerprint 0, then you write fingerprint and on the other side you ahve to 0 out the fingerprint to check and so on. I wrote such code over protocols and it's very fragile.
  3.  second, even if we do I don't think we improve the attack envelope or actually worsen it. Let's go through it
     *   major version is attacked, any change will drop the packet due to mismatch. if we protect it, we calculate the hash and it fails and outcome is the same modulo we can be computationally overrun
     *   outer key id is attacked/fingerprint length is attacked, all same outcome ...

now, you can argue that an attacker can modify stuff _behind_ the fingerprint and with that attack protocol computationally but there is no way around that, we won't detect modification otherwise wheeras modifying major version/key id/fingerprint lenght basically leads to drops on any change and protecting them only exposes us computationally for no benefit

There is a very weird case where one could record version X, wait until protocol runs X+1 and having matched the nonces (age of the universe probably not enough to get all those conditions in place), modify packets recorded with X to major version X+1 and see whether the parser will croak. Given the parser is model-based and we saw that it deals with the issue of umatching models fine by omitting, filling in defaults etc even that is not really a viable attack

--- tony
________________________________
From: Bruno Rijsman <brunorijsman@gmail.com>
Sent: Sunday, July 21, 2019 6:39 AM
To: Tony Przygienda <tonysietf@gmail.com>
Cc: rift@ietf.org <rift@ietf.org>
Subject: Re: RIFT fingerprint coverage

Fixing one important mistake in bold red below:


On Jul 21, 2019, at 11:35 AM, Bruno Rijsman <brunorijsman@gmail.com<mailto:brunorijsman@gmail.com>> wrote:

Hi Tony and others,

I just noticed that the RIFT fingerprints do not cover the key-id nor the fingerprint-length nor the major-version.

This means that if an adversary changes the key-id, fingerprint-length, or major-version, it will not be detected by the fingerprint.

I cannot think of an immediate attack vector (maybe force a weaker algorithm by changing the key-id), but "it feels wrong".

I wonder whether we should expand the coverage of fingerprints slightly, as shown below?

Note that AFAIK in OSPF (for example) the digest does cover the key-id and auth-data-len.

Suggested change:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      UDP Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Source Port         |       RIFT destination port   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           UDP Length          |        UDP Checksum           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Outer Security Envelope Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           RIFT MAGIC          |         Packet Number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved   |  RIFT Major   | Outer Key ID  |    Outer      |
      |               |    Version    |               | Fingerprint   |
      |               |               |               |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~  Outer Security Fingerprint covers all content starting       ~
      |  at the Reserved field in the Outer Security Envelope Header  |
      |  but excluding this fingerprint                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Weak Nonce Local              | Weak Nonce Remote             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Remaining TIE Lifetime (all 1s in case of LIE)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      TIE Origin Security Envelope Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                               |  TIE Origin   |
      |              TIE Origin Key ID                |  Fingerprint  |
      |                                               |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~  TIE Origin Security Fingerprint covers all content starting  ~
      |  at the TIE Origin Key ID field but excluding this fingerprint|
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Serialized RIFT Model Object
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                Serialized RIFT Model Object                   ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PS 1: I know that the rift-magic and packet-nr fields are left out of the fingerprint coverege on purpose, so I left it that way.

PS 2: I also updated the names have a clearer distinction between the two fingerprints.

— Bruno