From nobody Sat Feb 1 12:17:23 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3631201AA for ; Sat, 1 Feb 2020 12:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.com 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 PlG9qtt8Dn_H for ; Sat, 1 Feb 2020 12:17:18 -0800 (PST) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFA9120154 for ; Sat, 1 Feb 2020 12:17:18 -0800 (PST) Received: by mail-oi1-x236.google.com with SMTP id i1so10875147oie.8 for ; Sat, 01 Feb 2020 12:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pzekU9svsca6lfGpW2c6KAqcewWMI20I67kAWeWVr88=; b=U75n1rB+50/B/uV/JzdaXPZ3S/o4xFps/iDNzybfTIeply2Tp2ughy86oIm6jOwl9w cA9pZBi5Y5yF4Dmc013Vh/ezRvhS3AmJm7YP6/xv4lZxVeRJXzoGlQTk4kB+Cl70QmZN 2ZWuIrEOQkBiJdBfJep+K3uRYRtCx4jpbPJPj9VOz7Ru27t9hQgC7Adm+GdjHSpH1ody HaKMuaNVfSjEhBHSIZilkMaNUFuCTSgUuxPdovc/XLUZEdGh3IBudFKhxA6rxmhdwypy VBdnmb3i4ky68uNMEZc48Ix3VVX4l9KRoxYyilUlkGAC+gOs2Zf12oJW9oxRdQSrLgJk BQfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pzekU9svsca6lfGpW2c6KAqcewWMI20I67kAWeWVr88=; b=KSqVBG2F5EWzeYnWjmi2qGpTYK4EGC4Q2tGIjWzr8RzrAQNlJ8BuUy6eC9yQKDc5k/ 67fUd/zN7pvvHV9rhKS2nyPCkfhp+zKm18vXyFXCZoxi3/+fzbOXkzoMbwlnHatdoj6G ndkwV1wgENNxSFAPbLeoeE64qYm1ycvZ6cFaSe1kLh7AjGor+9whQ/Ku/UEwAdKdX+JP XHx0w53nntAxqOtFDs72XUNx8fPLU/dlnrooq+CPiDcDyx7nwZrhxXJumDix7tcIeikl uIbD4Ezh1Ow7x8FI6J1EVfG5rOEP1pjPAp120rselUIkyJwk8HrkcdjDuKNAn60aBtZP HNSw== X-Gm-Message-State: APjAAAXye/0lTlrD6btAEZAq/l2wXXrsJmlvVe+jbt1XEh1B3yKki0pe sNzWGb/0Nm94YammFCPCbtunL3pVN8hfDV1wiyc= X-Google-Smtp-Source: APXvYqzvF4iFEJGGO19O3OhXi2Qn99+PrJZi8dtlDc7rGZKmBBbsjssbkcAu6kEWc1nhpqYH01DvzdLvFa6KBdWURpg= X-Received: by 2002:a05:6808:319:: with SMTP id i25mr10318937oie.128.1580588237825; Sat, 01 Feb 2020 12:17:17 -0800 (PST) MIME-Version: 1.0 References: <20200109114608.GA24582@corley.shackle.nl> <20200121080553.GA18351@corley.shackle.nl> In-Reply-To: <20200121080553.GA18351@corley.shackle.nl> From: Alexander Azimov Date: Sat, 1 Feb 2020 23:17:06 +0300 Message-ID: To: Luuk Hendriks Cc: SIDR Operations WG Content-Type: multipart/alternative; boundary="00000000000073a9e6059d896011" Archived-At: Subject: Re: [Sidrops] Clarification of draft-ietf-sidrops-aspa-verification-03 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 20:17:21 -0000 --00000000000073a9e6059d896011 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Luuk, Thank you for another good question. Your understanding is correct: with the ASPA technique, you can detect only mistakes when the route is received from a provider or RS. It is explicitly stated in the security considerations (Sec. 8): While the ASPA is capable to detect both mistake and malicious activity for routes received from customers, RS-clients or peers, it provides only detection of mistakes for routes that are received from upstream providers and RS(s). While this is limiting your opportunity to detect malicious activity, the only attack scenario is when a provider sends malformed routes to its customer. At the same time, IMO the opportunity to detect even mistake leaks coming from providers is great. I recently modeled the work of ASPA algorithms on top of BMP data in Yandex - it worked and already showed valuable results. =D0=B2=D1=82, 21 =D1=8F=D0=BD=D0=B2. 2020 =D0=B3. =D0=B2 11:05, Luuk Hendri= ks : > Hi Alexander, all, > > On Tue 14 Jan 2020, 18:04, Alexander Azimov wrote: > > In the terms of the draft AS0->AS1->AS2 is an upstream path, while > AS3->AS4 > > is a downstream path. > > The invalid state of (AS2, AS3) pair triggers the change of the > > 'direction', but the following downstream path verification procedure i= s > > not applicable to (AS3, AS2) since it can be a peering link, that's why > I++ > > is used. > > Thanks for clarifying, it seems that we did interpret those parts of the > draft > correctly then. But we are still wondering whether skipping the check > after the > direction change is introducing a problem. (Again, this might be us not > having > much operational experience with actual routing, so please bear with me..= ) > > > What if a bad actor, AS9, inserts itself in the path like this: > > +-----+ > +--------> AS2 +--------+ > | +--+--+ | > +-----+ | +--v--+ > +------->+ AS1 | | +----->| AS3 +--------+ > | +-----+ | | +--^--+ | > +-----+ +-v-+-+ +--v--+ > | AS0 | | AS9 | | AS4 | > +-----+ +-----+ +-----+ > | > +--v--+ > | AS5 | > +-----+ > > No valid (AS2, AS9) ASPA is found, so we assume it is a peering link (the > I++). Direction is changed, so continuing, (AS3, AS9) and (AS4, AS3) are > checked. Now, if and only if any of these yield Invalid, the final result > will > be Invalid. Otherwise, the result will be Valid or Unknown, even though > there is > a malicious AS in the path. In other words, is the draft in its current > revision > beneficial without (close to) 100% adoption? > Or, is this situation not considered a problem in reality due to the long= er > AS_PATH and thus a lower preference anyway? > > > Thanks, > luuk > --=20 Best regards, Alexander Azimov --00000000000073a9e6059d896011 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Luuk,

Thank you for another good que= stion.
Your understanding is correct: with the ASPA technique, yo= u can detect only mistakes when the route is received from a provider or RS= .

It is explicitly stated in the security consider= ations (Sec. 8):
   While the ASPA is capable to detect both mistake and malicious
   activity for routes received from customers, RS-clients or peers, it
   provides only detection of mistakes for routes that are received from
   upstream providers and RS(s).

While this is limiting your opportunity to = detect malicious activity, the only attack scenario is when a provider send= s malformed routes to its customer. At the same time, IMO the opportunity t= o detect even mistake leaks coming from providers is great. I recently mode= led the work of ASPA algorithms on top of BMP data in Yandex - it worked an= d already showed valuable results.

=D0=B2=D1=82, 21 =D1=8F=D0=BD= =D0=B2. 2020 =D0=B3. =D0=B2 11:05, Luuk Hendriks <luuk@nlnetlabs.nl>:
Hi Alexander, all,

On Tue 14 Jan 2020, 18:04, Alexander Azimov wrote:
> In the terms of the draft AS0->AS1->AS2 is an upstream path, whi= le AS3->AS4
> is a downstream path.
> The invalid state of (AS2, AS3) pair triggers the change of the
> 'direction', but the following downstream path verification pr= ocedure is
> not applicable to (AS3, AS2) since it can be a peering link, that'= s why I++
> is used.

Thanks for clarifying, it seems that we did interpret those parts of the dr= aft
correctly then. But we are still wondering whether skipping the check after= the
direction change is introducing a problem. (Again, this might be us not hav= ing
much operational experience with actual routing, so please bear with me..)<= br>

What if a bad actor, AS9, inserts itself in the path like this:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +----= ----> AS2 +--------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 +--+--+=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----+=C2=A0= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--v--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 +------->+ AS1 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = | +----->| AS3 +--------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----+=C2=A0 =C2= =A0 =C2=A0 =C2=A0 | |=C2=A0 =C2=A0 =C2=A0 +--^--+=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 =C2=A0 =C2=A0+-----+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 +-v-+-+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--v--+
=C2=A0 =C2=A0 =C2=A0| AS0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 | AS9 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | AS4 |
=C2=A0 =C2=A0 =C2=A0+-----+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 +-----+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +-----+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--v--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| AS5 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----+

No valid (AS2, AS9) ASPA is found, so we assume it is a peering link (the I++). Direction is changed, so continuing, (AS3, AS9) and (AS4, AS3) are checked. Now, if and only if any of these yield Invalid, the final result w= ill
be Invalid. Otherwise, the result will be Valid or Unknown, even though the= re is
a malicious AS in the path. In other words, is the draft in its current rev= ision
beneficial without (close to) 100% adoption?
Or, is this situation not considered a problem in reality due to the longer=
AS_PATH and thus a lower preference anyway?


Thanks,
=C2=A0luuk


--
Best regards,
Alexander Azi= mov
--00000000000073a9e6059d896011-- From nobody Thu Feb 6 19:11:30 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0811F12008D for ; Thu, 6 Feb 2020 19:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 hyjLCW-n0UbU for ; Thu, 6 Feb 2020 19:11:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 AE14812001B for ; Thu, 6 Feb 2020 19:11:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1izu3C-0000zL-B4 for sidrops@ietf.org; Fri, 07 Feb 2020 03:11:26 +0000 Date: Thu, 06 Feb 2020 19:11:25 -0800 Message-ID: From: Randy Bush To: SIDR Operations WG User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] 8210bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 03:11:30 -0000 we're working on 8210bis, The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 1.2. Changes from RFC 8210 This section summarizes the significant changes between [RFC6810] and the protocol described in this document. o New ASPA PDU type (Section 5.12) added to support [I-D.ietf-sidrops-aspa-profile]. o Protocol version number incremented from 1 (one) to 2 (two). while we're doing the ASPA PDU hack, do any implementors of 6810/8210 have comments based on experience implementing 6810/8210? randy From nobody Sat Feb 8 01:37:16 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DE21200B1 for ; Sat, 8 Feb 2020 01:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 ABbyG56d1pi3 for ; Sat, 8 Feb 2020 01:37:14 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 E6C2212003E for ; Sat, 8 Feb 2020 01:37:13 -0800 (PST) Received: from grisu.home.partim.org (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id E6F221335A; Sat, 8 Feb 2020 10:37:10 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Sat, 8 Feb 2020 10:37:10 +0100 From: Martin Hoffmann To: Randy Bush Cc: SIDR Operations WG Message-ID: <20200208103710.249e8166@grisu.home.partim.org> In-Reply-To: References: Organization: Open Netlabs X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] 8210bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2020 09:37:15 -0000 Randy Bush wrote: >=20 > while we're doing the ASPA PDU hack, do any implementors of 6810/8210 > have comments based on experience implementing 6810/8210? The one thing that tripped me up when implementing RTR was that the content of the End-of-data PDU had changed between versions 0 and 1 and this isn=E2=80=99t properly mentioned in 8210 (there=E2=80=99s a vague note= in section 1.2 that one can really only interpret correctly in hindsight). Since the old format isn=E2=80=99t mentioned but in practice you will have to implement version 0, you need to read and implement an obsoleted RFC which seems a bit wrong to me. It would be good if 8210bis would at least stick a big warning at its equivalent to section 5.8 or, better yet, show the format for version 0 as well. The other thing that is a bit iffy when implementing is that for the Router Key PDU the flags field is moved from the payload into to the header repurposing part of what is the session ID when present. Maybe for the ASPA PDU you could keep it in the payload? Kind regards, Martin =20 From nobody Sat Feb 8 19:19:15 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291F812008B for ; Sat, 8 Feb 2020 19:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 tE4OEdg_wpXY for ; Sat, 8 Feb 2020 19:19:12 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 A6638120077 for ; Sat, 8 Feb 2020 19:19:12 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1j0d7l-0001Vm-KG; Sun, 09 Feb 2020 03:19:09 +0000 Date: Sat, 08 Feb 2020 19:19:07 -0800 Message-ID: From: Randy Bush To: Martin Hoffmann Cc: SIDR Operations WG In-Reply-To: <20200208103710.249e8166@grisu.home.partim.org> References: <20200208103710.249e8166@grisu.home.partim.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] 8210bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2020 03:19:14 -0000 >> while we're doing the ASPA PDU hack, do any implementors of 6810/8210 >> have comments based on experience implementing 6810/8210? your comments really appreciated > The one thing that tripped me up when implementing RTR was that the > content of the End-of-data PDU had changed between versions 0 and 1 and > this isn=A2t properly mentioned in 8210 (there=A2s a vague note in section > 1.2 that one can really only interpret correctly in hindsight). Since > the old format isn=A2t mentioned but in practice you will have to > implement version 0, you need to read and implement an obsoleted RFC > which seems a bit wrong to me. >=20 > It would be good if 8210bis would at least stick a big warning at its > equivalent to section 5.8 or, better yet, show the format for version > 0 as well. both done. > The other thing that is a bit iffy when implementing is that for the > Router Key PDU the flags field is moved from the payload into to the > header repurposing part of what is the session ID when present. yuchhh! > Maybe for the ASPA PDU you could keep it in the payload? 5.12. ASPA PDU 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | zero | | 2 | 11 | | +-------------------------------------------+ | | | Length | | | +-------------------------------------------+ | | | | | Flags | zero | Provider AS Count | | | | | +-------------------------------------------+ | | | Customer Autonomous System Number | | | +-------------------------------------------+ | | | Provider Autonomous System Number | | | ~-------------------------------------------~ The ASPA PDU is to support [I-D.ietf-sidrops-aspa-profile]. The lowest-order bit of the Flags field is 1 for an announcement and 0 for a withdrawal. Withdrawal of a non-existant or non-matching ASPA PDU is an error. The Provider AS Count is the number of 32-bit Provider Autonomous System Numbers in the PDU. There may be none. The Customer Autonomous System Number is the 32-bit Autonomous System Number of the customer which signed the PDU. There may be only one ASPA for a Customer Autonomous System Number active at any time. There are zero or more 32-bit Provider Autonomous System Number fields; see [I-D.ietf-sidrops-aspa-profile]. From nobody Sat Feb 8 19:32:52 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1444B12008B for ; Sat, 8 Feb 2020 19:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ZEVrEZqf4NMc for ; Sat, 8 Feb 2020 19:32:50 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 E6161120077 for ; Sat, 8 Feb 2020 19:32:49 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1j0dKy-0001XP-Qw; Sun, 09 Feb 2020 03:32:49 +0000 Date: Sat, 08 Feb 2020 19:32:48 -0800 Message-ID: From: Randy Bush To: Martin Hoffmann Cc: SIDR Operations WG In-Reply-To: References: <20200208103710.249e8166@grisu.home.partim.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] 8210bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2020 03:32:51 -0000 and implementor feedback on this would be appreciated The ASPA PDU is to support [I-D.ietf-sidrops-aspa-profile]. Receipt of an ASPA PDU announcement when the router already has an ASPA PDU with the same Customer Autonomous System Number, replaces the previous one. This is to avoid surprises when a BGP announcement is received between an withdrawn PDU and a new announced PDU. randy From nobody Sat Feb 8 21:51:47 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A1C1200B7 for ; Sat, 8 Feb 2020 21:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 i20zFJYWNaTi for ; Sat, 8 Feb 2020 21:51:44 -0800 (PST) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.10]) (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 EAD3A12008B for ; Sat, 8 Feb 2020 21:51:43 -0800 (PST) Received: from grisu.home.partim.org (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 966F213FA9; Sun, 9 Feb 2020 06:51:41 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Sun, 9 Feb 2020 06:51:40 +0100 From: Martin Hoffmann To: Randy Bush Cc: SIDR Operations WG Message-ID: <20200209065140.62e40665@grisu.home.partim.org> In-Reply-To: References: <20200208103710.249e8166@grisu.home.partim.org> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] 8210bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2020 05:51:46 -0000 Randy Bush wrote: >=20 > There are zero or more 32-bit Provider Autonomous System Number > fields; see [I-D.ietf-sidrops-aspa-profile]. As a mere implementer, I can=E2=80=99t really judge how many Provider ASNs a single ASPA typically will have, so I am just throwing this out there for consideration: ROAs are decomposed into a separate PDU for each prefix. The advantage is that the PDUs are fixed size and I can keep read buffers on the stack, whereas for variable length PDUs I will have to have some kind of allocation strategy. Obviously, there is a 96 byte overhead for each additional Provider ASN if we did the same for ASPAs.=20 Am I assuming correctly that decomposing the ASPA would also make the other paragraph you were asking for feedback for unnecessary: > The ASPA PDU is to support [I-D.ietf-sidrops-aspa-profile]. Receipt > of an ASPA PDU announcement when the router already has an ASPA PDU > with the same Customer Autonomous System Number, replaces the > previous one. This is to avoid surprises when a BGP announcement is > received between an withdrawn PDU and a new announced PDU. Kind regards, Martin From nobody Mon Feb 10 09:37:51 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCD612080E; Mon, 10 Feb 2020 09:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 YjBK0e11Zdo1; Mon, 10 Feb 2020 09:37:47 -0800 (PST) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl0gcc02on20713.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d05::713]) (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 D30E812001B; Mon, 10 Feb 2020 09:37:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jWfdo2v1PUGwlArjCCpcf7VGeN5mgtK8Tf1I2F2hxXJryOj2Y6rgQp5APiPfdgjXQ7FbdjvSsw3jJtR5Zn01PKCrx4lH4f9gwvIlrJfbFoCcIAN5AmkRzI3RpVP7Mwx3ZsJg8N3OGuAWVPxG+F0Yo1yfgeblYl9rhPmb0f2fjb1EBJZCVmH17ZU81vwSPq7spw98gtbGe0bw0LFbSRsjkh869crc0aRDdbVwUpkIIU9CiPfBMvJmI5N6CBjBkKU+P5PqdL9tLC+F55RkEMXf/Hi/BAZcfi9mQokG/+TFqhXb8twyi+qpUMjCR4PuZH9ELAPEDYoeK6i6AoLzQro4oQ== 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=ovG0dGRIM6BeLZL310M085QzCDSn89RLmWK2NZt4MNM=; b=e4c25cwWe5psUhhuT7qOv6UaHacKAfohqr5/C3S+FyPMaHvEnNXmaAYFD4AORM53A1wU1lVWoBfq30WiDz8EddGOcCLQ7kwpwgb/xbjwgaaK/Q4oBlmsOC38UofZUq81wm6caa3xXl4hKYnpIl+Eu1gphVDNgqHDfmjA5vUFNFlMlWyZF+VXUKfTplexBiVhPEJrZHYClzdeFDbbr3LIfgk3c53DMytOgUCQ1+vQ6FyI9gOxH5ICL01YhsJjnmYDCOiVDN6GQZpVQbAnS8pYVnrW2SAV2h8R1g1MZnda48BoK5iVlNG2kQj/vmno4FRGh+O+rYYzVaUFyX+BcBvtQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ovG0dGRIM6BeLZL310M085QzCDSn89RLmWK2NZt4MNM=; b=tkz7VRZ1a9DK1QQKmvVSCJnoaKZhjRlewelXRuCzqv1vRPIE3LC9SCQb1bOEQCXBBmIoxBfqCp2w0E6D+acep4WafLHpcdThjJ4tZuMpdJ2wI0S4xiVfaGd/8zswszD+RqjcgHk0PEdz1yrYA34baqosXEa01AiD/TofYLK9pgw= Received: from CH2PR09MB4571.namprd09.prod.outlook.com (10.186.138.209) by CH2PR09MB4540.namprd09.prod.outlook.com (10.186.137.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Mon, 10 Feb 2020 17:37:40 +0000 Received: from CH2PR09MB4571.namprd09.prod.outlook.com ([fe80::7c1e:6458:a461:cd4]) by CH2PR09MB4571.namprd09.prod.outlook.com ([fe80::7c1e:6458:a461:cd4%3]) with mapi id 15.20.2707.030; Mon, 10 Feb 2020 17:37:40 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "grow@ietf.org" CC: "sidrops@ietf.org" Thread-Topic: [OPSEC] BCP 84, RFC 8704 on Enhanced Feasible-Path Unicast Reverse Path Forwarding Thread-Index: AdXgM/+fEA66ukMMRQmkBvs8PWN/4A== Date: Mon, 10 Feb 2020 17:37:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.161] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 386abd3f-4ba0-4d0d-1abf-08d7ae4fed7f x-ms-traffictypediagnostic: CH2PR09MB4540: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03094A4065 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(136003)(366004)(376002)(39860400002)(199004)(189003)(966005)(52536014)(5660300002)(76116006)(478600001)(66446008)(33656002)(66556008)(66946007)(64756008)(66476007)(316002)(8936002)(81166006)(81156014)(8676002)(71200400001)(6916009)(86362001)(4326008)(2906002)(450100002)(9686003)(66574012)(6506007)(55016002)(186003)(7696005)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR09MB4540; H:CH2PR09MB4571.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ycBVeYPnkM5GIIhHI0usyneTKSauz/+T6VQIVC5gxOgVcf0l8kYhVn+0auoAIyYAmOf13csnPAiVq2FEA2ff2zQAZCtok+jQ3YTqUrabMqcXq0+JVogX7OI+X3Ng8lSk5JTV2Zf+qPipnICH+BSsR/djoYeNaxtBp8e5lbUuNqggR7xOOSdSSECxiDhxYjc5SViRME++R0CzZiwqqllYnNprkBJ0g1UpQkqhRoEqe4lg80vo86a3GqvhEFXwObrcp8owa6burobi/bpC/QkTra1GZ8PeLfIoNmrwhk4yNwx5EodMLgkCClBddrHDEpeAkSTCu4Ty6FcT/gbg85gJ81HWPihkOtBYiz7hh8R7s5k2DNC2YmDWNpmsP+Y9dyAMw9IqPAUug9NIkDM4y0f9GIxRKNwZDvj6KceGg3UgqIDNhzrO2+NHSQxOGwlYCon7sq33s5q1JNxmGrMRNMcbBH3zOrvJNVuUw9H8AbJsIth6FlD5GLbENtAv44ZshXsooBQTXYcYZAp+Cv8KYIepew== x-ms-exchange-antispam-messagedata: Rd/4bvZXV0u8w2p/6baEXB7EOZ/FZ7T8jPf42qEQ918rMAujmLvaxePWlQuAIgz+rQe9Y88TRfaVpNpTyaTaX9AtCxfhOfK6Te/HLZZBoMHgLIbC2xphDfzf+2dxy83VbQAkocrzAj6Ne05Z8B4WyA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 386abd3f-4ba0-4d0d-1abf-08d7ae4fed7f X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2020 17:37:40.5408 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PA53LtTYFoo6Hp9gbyONQ8Neva0ukvDND8qGCsN2VwX3vHqhNA1z76pXYKNesM9o9kalqxSNG1C103b9Sv0YmA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR09MB4540 Archived-At: Subject: [Sidrops] FW: [OPSEC] BCP 84, RFC 8704 on Enhanced Feasible-Path Unicast Reverse Path Forwarding X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 17:37:50 -0000 This new RFC is a product of the OPSEC WG. https://tools.ietf.org/html/rfc8704 I thought I should share the publication notice in GROW because=20 substantial discussion and feedback occurred also in=20 the GROW WG when this RFC was in draft form. Thank you. CC'ing SIDROPS WG also since the RFC (BCP) recommendations=20 include using ROA data as part of the overall EFP-uRPF scheme.=20 Sriram ------------------------- A new Request for Comments is now available in online RFC libraries. BCP 84 =20 RFC 8704 Title: Enhanced Feasible-Path Unicast Reverse Path=20 Forwarding=20 Author: K. Sriram, D. Montgomery, J. Haas Status: Best Current Practice Stream: IETF Date: February 2020 Mailbox: ksriram@nist.gov,=20 dougm@nist.gov,=20 jhaas@juniper.net Pages: 17 Updates: RFC 3704 See Also: BCP 84 I-D Tag: draft-ietf-opsec-urpf-improvements-04.txt URL: https://www.rfc-editor.org/info/rfc8704 DOI: 10.17487/RFC8704 This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704. This document is a product of the Operational Security Capabilities for IP = Network Infrastructure Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for=20 improvements. Distribution of this memo is unlimited. *************** From nobody Mon Feb 24 07:15:44 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C220F3A0CE1 for ; Mon, 24 Feb 2020 07:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 SXXbH2OdZ_DC for ; Mon, 24 Feb 2020 07:15:40 -0800 (PST) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F45D3A0CDE for ; Mon, 24 Feb 2020 07:15:36 -0800 (PST) Received: by mail-wr1-f54.google.com with SMTP id l5so6555905wrx.4 for ; Mon, 24 Feb 2020 07:15:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=Hk2hZyCm9a0eRCwbGojXqdhV6JHpVWbdy6LG1VvlWEo=; b=L7YFiuLt9lVzYTpOGU/o9YsFcJKbm63kVOthnnoC9km9/pT+9pVFBX+VQlt9A/qnJj 0eijgPE3a7auk4/v2O3w72kx/YY6LQYrMRATVefFSruzJvGcBwMMpSAvjc47T39xqHK3 VuAZIxIHHDxtVM6iG6ATRNJ8/8306f6U3TbbIIJbUEetPVTqY9krbtMo00RiRSxe3Jit 1z1i04fCUXCPg1WnlUCPGQXcGeI2CanuraQRw1zzxzklcTIESPKMrQY2cy8QvdjJsaGU z/YH0X83gu7pw8AumfxnqOx25UqT0mI2Fr5mCJ96FAtpdq10ixml0ND+JLrAV6d75aDI +guA== X-Gm-Message-State: APjAAAVi3hI3Qxqh/D5NJvacYcqnEtx+29GGPGAh3t5vKb/LnVMBvSTb OViAbpxtWRQP9oVwAzSUa4soyA== X-Google-Smtp-Source: APXvYqxB3RO+u769C5j69n8xJ5R0xNc9cqycWGg5Pu+YfguD+Vt0PrOZq5k0N5z0bamKGrpSrO0CqQ== X-Received: by 2002:a5d:4750:: with SMTP id o16mr66499765wrs.91.1582557335028; Mon, 24 Feb 2020 07:15:35 -0800 (PST) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id b13sm20578304wrq.48.2020.02.24.07.15.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Feb 2020 07:15:34 -0800 (PST) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 1626d1e5; Mon, 24 Feb 2020 15:15:33 +0000 (UTC) Date: Mon, 24 Feb 2020 15:15:32 +0000 From: Job Snijders To: sidrops@ietf.org, claudio@openbsd.org Message-ID: <20200224151532.GD19221@vurt.meerval.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 15:15:43 -0000 Hi group, It seems we need guidance and consensus on what to do when the CRL is hosed in some way or shape. We have two implementation discrepancies pop up recently: https://github.com/NLnetLabs/routinator/issues/274 RIPE NCC's top level CRL expired this weekend (https://www.ripe.net/support/service-announcements/rpki-infrastructure-issues) https://lists.nlnetlabs.nl/pipermail/rpki/2019-December/000109.html OpenBSD's rpki-client uses the x509 certificate validation functions that come from libressl, which doesn't have a button to turn off only CRL timestamp verification. I was told that some nasty code would be required to work around that, so one can argue that rolling things by hand in X509 handling rarely is a great idea. One could also argue that a softer landing is needed, unavailability of the CRL should mean that only the CRL itself is not available and proceed to validate the tree without the revocation list. I can see how that is helpful in some circumstances. So, what to do? Whatever it is, ideally all validators follow a similar process. Kind regards, Job From nobody Mon Feb 24 09:58:02 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E60C3A1013 for ; Mon, 24 Feb 2020 09:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 esv3fI0QOTRe for ; Mon, 24 Feb 2020 09:58:00 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 656D33A100A for ; Mon, 24 Feb 2020 09:58:00 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1j6HzS-0002ll-17; Mon, 24 Feb 2020 17:57:58 +0000 Date: Mon, 24 Feb 2020 09:57:57 -0800 Message-ID: From: Randy Bush To: Keyur Patel Cc: SIDR Operations WG In-Reply-To: <90BC571C-6BE7-4462-ACE9-4AF01BE3245A@arrcus.com> References: <2384EDD7-3C8D-45C9-9D21-1143B13BF996@arrcus.com> <90BC571C-6BE7-4462-ACE9-4AF01BE3245A@arrcus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] WGLC for draft-ietf-sidrops-ov-egress-00.txt - ENDS 11/25/2019 (November 25 2019) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 17:58:02 -0000 on december 1: > WGLC has ended. This draft did not get any significant comments or > pushback. We will push the draft forward to IESG. perhaps the co-chairs will come out of (northern hemespheric) winter hibernation soon and move this forward? randy From nobody Mon Feb 24 10:46:17 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1713A10ED for ; Mon, 24 Feb 2020 10:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com 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 m2uIawImF3Hi for ; Mon, 24 Feb 2020 10:46:13 -0800 (PST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2060.outbound.protection.outlook.com [40.107.237.60]) (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 DC6853A10EB for ; Mon, 24 Feb 2020 10:46:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GkfS+ZAIrPWLA4pR/erjnxrPg/5o9ZNtBg97ZZZGLrb+JDIiiidALRERT2dePvMWTazTmPvzWvo+PDxsl3sF0dI4u0m2AChwR3kyemEN4uL9C7WkrM5GTd/ADTwi4eDgo758DNcWj9e/jPmscSx6PxyfzSSqWPPlpwxpq7ycYY2CiQ9hnDV9jsPN4Ls3KQ+SybXX267Xkk4SeQjYanxau9VJC/8qPIzaCe5Vdt9ejQtEKFOABr/BDDoK/YpZeFhuQ+6zHxpL//1S4iitVn6Ngt0Dn6lCqzCwPwuCsBgo6h2XmuLggbkCfvUznxtAByJ39PqKJgqcSN3MHP2ODpWe8g== 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=wAv3rYhad1R6cQEr46NLP+wWNFymNpXT0kW3k4E7Yrs=; b=QYPcOkJWcEW413GNf0TZ3brgG6RmM45OULpK6Uq933APB9rC6DoKYSEaELJGNRJU1/ck1u6I0MK8pmMoAiEAjzHhyaj5LQ33Dt+71IwBNVa5babS5rOU6nh4BsGjlko9P1e44VDHbGbddwy1LIP20qLa2/bNG4koLwCHAatxyGFS+RyVNWILfN0TRgzTTDwXk8dDhMQt7F7wG+aZgmMGqmcuLibnu2hbHOUPNsEkJ72LBiYm3cAfGpHT/qXFwqzJZaKyMOglkeY5MWKFp7K1s7TCuFc2+f/0+44Knl2a03Ablt4FisPX8Zc0pRccVLKNZUDLt5R0TkEHG8ZGQPPGxA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wAv3rYhad1R6cQEr46NLP+wWNFymNpXT0kW3k4E7Yrs=; b=A8y/s9ZwtzcwwzRZNAS0yFTTq57BM647hkN5sQ6fZGTmO+JTS1nsgknqA2rqF3ZwY1GQ5HgKcuX70TCI/IY+FJnP/oYXMemxmw15kwZTsNvVjK5wRr04xK2R9HXFWmm2x8LJqs7QoakxaPbfpx+5mSzmlzk54AxaHXQDk0JkuYw= Received: from BYAPR18MB2856.namprd18.prod.outlook.com (2603:10b6:a03:10e::30) by BYAPR18MB2533.namprd18.prod.outlook.com (2603:10b6:a03:12c::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Mon, 24 Feb 2020 18:46:10 +0000 Received: from BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::9ca8:5fd:8296:7b05]) by BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::9ca8:5fd:8296:7b05%4]) with mapi id 15.20.2750.021; Mon, 24 Feb 2020 18:46:10 +0000 From: Keyur Patel To: Randy Bush CC: SIDR Operations WG Thread-Topic: [Sidrops] WGLC for draft-ietf-sidrops-ov-egress-00.txt - ENDS 11/25/2019 (November 25 2019) Thread-Index: AQHVk2UfOuDycc3cSESF2qi5QSEwWqelOYwAgIYXjYCAAA14Mg== Date: Mon, 24 Feb 2020 18:46:09 +0000 Message-ID: References: <2384EDD7-3C8D-45C9-9D21-1143B13BF996@arrcus.com> <90BC571C-6BE7-4462-ACE9-4AF01BE3245A@arrcus.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [2600:387:6:803::34] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d41828fe-4309-4755-923c-08d7b959d0aa x-ms-traffictypediagnostic: BYAPR18MB2533: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39830400003)(376002)(366004)(396003)(136003)(199004)(189003)(6916009)(86362001)(2906002)(36756003)(81166006)(8936002)(186003)(508600001)(6506007)(53546011)(4326008)(8676002)(81156014)(66476007)(66946007)(4744005)(6512007)(66556008)(64756008)(316002)(6486002)(71200400001)(33656002)(76116006)(2616005)(66446008)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2533; H:BYAPR18MB2856.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pTdEP182SvGzaV9M/SSypRHeNVMdCanOrcKHd9XetVChww5vdqa3xJwOml/O7Fhhfcga/V6lWUf38r9o5xBVODdTTKg7CJ/Ws6n0L5ytFxJVEgnpnOQIjdF3fRdrZDtOlvL46zQSduk3sylUG8sCJM+ULekQ/ETyh2Q4ERTP4NrL1jF7BoaO3ia2LJgU2vO/E+ncovDw458Ac4bEaIf2SfC73Kn6Zcui70/0qrSe4FYGGKkk4c+CFhoNDUfWWmV5+DUen+1BcPYmlE8LV+a4RFE7/dXU5w44cu1gapM9yiBND784qj5MKfPbAHhDj8d/+QPFr70/mxcWblAWdJBBaMvFKyBQNRTgruNAcfu3PSI7Wqm9NKeWgEjzhj1NJ4u+BoK7Tz7MgpE+sCmuWjvDPgVjQWO1yRmte7RWjb9QBeVi5/TGS7F9G/IdWGPdnOxg x-ms-exchange-antispam-messagedata: TzSSrUT4YJugZWX0sjJgpWeKH8jsczPDpo830/eVoKviUrN686DMaQ4B9Jh8PgSc4A2xP8pTL1CEej41sm+SeJkHwYlOWfjneT/eX6FivnCUjo4sDTlgnQ+JeCqV5zrGGWjAfEOAYQ1SY1Qjy0eacgSh71V8o39z4G+LTxX4Vqc= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: d41828fe-4309-4755-923c-08d7b959d0aa X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2020 18:46:09.8892 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YtfHupRWwYkFdfzkgcTtyAoHjM5UtukOSdWdqTKdqSrlhmS30mTeXuK6t+dVYVTsphsQlfVfWUvYEVjQAQ8yww== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2533 Archived-At: Subject: Re: [Sidrops] WGLC for draft-ietf-sidrops-ov-egress-00.txt - ENDS 11/25/2019 (November 25 2019) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 18:46:15 -0000 WWVwLiBUaGFua3MuDQoNCj4gT24gRmViIDI0LCAyMDIwLCBhdCA5OjU4IEFNLCBSYW5keSBCdXNo IDxyYW5keUBwc2cuY29tPiB3cm90ZToNCj4gDQo+IO+7v29uIGRlY2VtYmVyIDE6DQo+PiBXR0xD IGhhcyBlbmRlZC4gVGhpcyBkcmFmdCBkaWQgbm90IGdldCBhbnkgc2lnbmlmaWNhbnQgY29tbWVu dHMgb3INCj4+IHB1c2hiYWNrLiBXZSB3aWxsIHB1c2ggdGhlIGRyYWZ0IGZvcndhcmQgdG8gSUVT Ry4NCj4gDQo+IHBlcmhhcHMgdGhlIGNvLWNoYWlycyB3aWxsIGNvbWUgb3V0IG9mIChub3J0aGVy biBoZW1lc3BoZXJpYykgd2ludGVyDQo+IGhpYmVybmF0aW9uIHNvb24gYW5kIG1vdmUgdGhpcyBm b3J3YXJkPw0KPiANCj4gcmFuZHkNCg== From nobody Mon Feb 24 12:55:28 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE753A12FC for ; Mon, 24 Feb 2020 12:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 sLMUvPyLTiZ7 for ; Mon, 24 Feb 2020 12:55:26 -0800 (PST) Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52BC3A12F9 for ; Mon, 24 Feb 2020 12:55:25 -0800 (PST) Received: by mail-wr1-f44.google.com with SMTP id l5so7822908wrx.4 for ; Mon, 24 Feb 2020 12:55:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=rruVFHpx6zIYcOjcwoSH7jNxVvfuZj4ABzFYR1GrtTU=; b=T8ziFdB9K0R208LpxrUpwQMOV2/gNoqTRu6l9ZFxKnYnl+yzLrPFmCI6du2ta0lcU9 FGaCMYAmDqs79Le97hX12hyplbDxHVXcx7wP04+CeedVDM7Dm19pLfiqU/zkXTqXAXia Nx4/geuh2/6SWRfVQVbGU+NlBwc++SIsimpFpwVAouTUreiJ2dg5LO3H+5kZcxeCzNL5 3hyQL6m4GSeoisIimKZotv4+F9srWMrz3Luokm6MqD4FnVTWQqBj+LtC1DwqWLzl8oOb nDKB2Gl8mN/Zf3J7d+sOX7GIloFILR+b/w7gQrsqGEFCA2RYX9Wzh4IOt4NiEQ4tsn7L Qk0A== X-Gm-Message-State: APjAAAWTLm0viahIm5qqMn9gJoof+rs9EVLvxLN09bYgmdMIpXJpf/d2 ePWGng3cJ8PZT0iYNy0AZuDCZg== X-Google-Smtp-Source: APXvYqyDc3+Benj6eai/XaoX5OA4uFi4e9wqNHQuGrtlA08PjnnE1KWiz1GUzC75RMhwJ/asgD6g6g== X-Received: by 2002:adf:a4c1:: with SMTP id h1mr70208552wrb.10.1582577723507; Mon, 24 Feb 2020 12:55:23 -0800 (PST) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id q14sm20827629wrj.81.2020.02.24.12.55.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Feb 2020 12:55:22 -0800 (PST) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 91448005; Mon, 24 Feb 2020 20:55:21 +0000 (UTC) Date: Mon, 24 Feb 2020 20:55:21 +0000 From: Job Snijders To: Claudio Jeker Cc: sidrops@ietf.org Message-ID: <20200224205521.GA60925@vurt.meerval.net> References: <20200224151532.GD19221@vurt.meerval.net> <20200224154449.GB86633@diehard.n-r-g.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200224154449.GB86633@diehard.n-r-g.com> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 20:55:27 -0000 Thanks claudio (forwarding this back to the list, seems claudio's mail for some reason didn't show up in the archives) On Mon, Feb 24, 2020 at 04:44:49PM +0100, Claudio Jeker wrote: > On Mon, Feb 24, 2020 at 03:15:32PM +0000, Job Snijders wrote: > > Hi group, > > > > It seems we need guidance and consensus on what to do when the CRL is > > hosed in some way or shape. We have two implementation discrepancies pop > > up recently: > > > > https://github.com/NLnetLabs/routinator/issues/274 > > RIPE NCC's top level CRL expired this weekend > > (https://www.ripe.net/support/service-announcements/rpki-infrastructure-issues) > > > > https://lists.nlnetlabs.nl/pipermail/rpki/2019-December/000109.html > > > > OpenBSD's rpki-client uses the x509 certificate validation functions > > that come from libressl, which doesn't have a button to turn off only CRL > > timestamp verification. I was told that some nasty code would be > > required to work around that, so one can argue that rolling things by > > hand in X509 handling rarely is a great idea. > > > > One could also argue that a softer landing is needed, unavailability of > > the CRL should mean that only the CRL itself is not available and > > proceed to validate the tree without the revocation list. I can see how > > that is helpful in some circumstances. > > > > So, what to do? Whatever it is, ideally all validators follow a similar > > process. > > The process at the moment is clear: the embedded X509 certificates > reference a CRL and so the validator has to check if that certificate was > revoked via the CRL. This verification needs to follow the procedure of > X509 certificate validation (which includes timestamp verification). > If you want a soft landing then please just remove the CRL from the > system. > > In general it is important that the timestamps in the various RPKI objects > are checked during verification. Not doing so will put you at risk for > replay attacks. > > -- > :wq Claudio From nobody Mon Feb 24 13:15:39 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE793A134E for ; Mon, 24 Feb 2020 13:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 kBJV5h7QvAjI for ; Mon, 24 Feb 2020 13:15:36 -0800 (PST) Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D233A134D for ; Mon, 24 Feb 2020 13:15:35 -0800 (PST) Received: by mail-wr1-f49.google.com with SMTP id g4so5788419wro.13 for ; Mon, 24 Feb 2020 13:15:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=OMGEdBQjjA+PcTnuvg8Mo+GkX1UanJDWW3xV0Cgcb0I=; b=NAuCspgt8NIlXelxCnHg1g517bmCc2kNKklZfLJPwb0COTlNYKtS/zpK7xOmzFHPES hPqQ/R4mbLuHCGHgLzOtoIo6QhW/AS5/CUsGedUICwgIAlGXDpAMm4cP1uF1x39mQ43d kFmbVWf9rHtsoAnCg36+VNL0XIcG98awgj82yrpCFTE2Lx9a0iMnXUextfCbvigLhlJq ISWqbotKrAuEyAP2Y0TDJka8PpSB2icKgw1wwEv2T5hq5+3m8NsP1sf8A994CXod3u6K /o4xd91NrkYsrMb0K+lv0xGW/rkZlguZlwNj35WFc0T4GanPC2MPUiRSkYL6ThAVOFCM woyA== X-Gm-Message-State: APjAAAV+faL12Luc6ahawQeiZvKxLC/mZGR+X5CNwRm3T1MXiDI6pF49 t5LVqjg/80i5NePLu0M3DH29iLjkULQ= X-Google-Smtp-Source: APXvYqzv36wuqyIWBOG2T2Yby90Euy3j2Ii+DVP4/4WLrUhLbm7Nrf/BLn1Ozvuapu6C33orUiFkbg== X-Received: by 2002:adf:e3cd:: with SMTP id k13mr44403667wrm.302.1582578933673; Mon, 24 Feb 2020 13:15:33 -0800 (PST) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id b10sm856387wmj.48.2020.02.24.13.15.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Feb 2020 13:15:32 -0800 (PST) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id a3fd9f25; Mon, 24 Feb 2020 21:15:31 +0000 (UTC) Date: Mon, 24 Feb 2020 21:15:31 +0000 From: Job Snijders To: sidrops@ietf.org, claudio@openbsd.org Message-ID: <20200224211531.GB60925@vurt.meerval.net> References: <20200224151532.GD19221@vurt.meerval.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200224151532.GD19221@vurt.meerval.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 21:15:38 -0000 To reply myself: In case the CRL expired, or is otherwise somehow invalid; and the cache validator continues to consider the entire validation tree to be valid for some purpose, the validator is vulnerable to replay attacks because the use of unencrypted transport such as rsync (which supported in all validators, by mandate) give no support to trust anything anymore. I think ignoring the CRLs state goes against the entire RPKI trust-model mindset. A cache validator MUST consider the certificate have been appeared on the Certificate Revocation List (CRL) issued by the CA represented by certificate if the CRL is expired. While one can argue in different contexts of the application of X509 technology different (more forgiving) policies can apply; in the use case of RPKI I think we cannot tolerate anything less than to assume the CA has failed when the CRL is inaccessible or expired. And those running CA's will want to take careful note of this critical operational aspect. Cache validator implementations which didn't stop parsing RIPE NCC's tree today, should be aware they are have a security issue and consider how to upgrade their validation strategy. I think OpenBSD's rpki-client was the only one to get it right today. Of course - in making strong statements like this one I can not afford to assume I am right, so if you disagree - please tell me how I am wrong (in detail :-) ). Kind regards, Job On Mon, Feb 24, 2020 at 03:15:32PM +0000, Job Snijders wrote: > Hi group, > > It seems we need guidance and consensus on what to do when the CRL is > hosed in some way or shape. We have two implementation discrepancies pop > up recently: > > https://github.com/NLnetLabs/routinator/issues/274 > RIPE NCC's top level CRL expired this weekend > (https://www.ripe.net/support/service-announcements/rpki-infrastructure-issues) > > https://lists.nlnetlabs.nl/pipermail/rpki/2019-December/000109.html > > OpenBSD's rpki-client uses the x509 certificate validation functions > that come from libressl, which doesn't have a button to turn off only CRL > timestamp verification. I was told that some nasty code would be > required to work around that, so one can argue that rolling things by > hand in X509 handling rarely is a great idea. > > One could also argue that a softer landing is needed, unavailability of > the CRL should mean that only the CRL itself is not available and > proceed to validate the tree without the revocation list. I can see how > that is helpful in some circumstances. > > So, what to do? Whatever it is, ideally all validators follow a similar > process. > > Kind regards, > > Job From nobody Mon Feb 24 14:19:39 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB93E3A0FE2 for ; Mon, 24 Feb 2020 14:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 MmnLeJZvAxqU for ; Mon, 24 Feb 2020 14:19:36 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC99E3A1471 for ; Mon, 24 Feb 2020 14:19:36 -0800 (PST) Received: from [10.228.78.192] (mobile-166-170-27-115.mycingular.net [166.170.27.115]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id D79A15400EE; Mon, 24 Feb 2020 17:19:34 -0500 (EST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Jared Mauch In-Reply-To: <20200224211531.GB60925@vurt.meerval.net> Date: Mon, 24 Feb 2020 17:19:33 -0500 Cc: sidrops@ietf.org, claudio@openbsd.org Message-Id: <10259FC6-FE65-4B34-81B2-A37FCFA29BF2@puck.nether.net> References: <20200224211531.GB60925@vurt.meerval.net> To: Job Snijders X-Mailer: iPhone Mail (17D50) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 22:19:38 -0000 I think you may be right in absolute terms. You are likely wrong that unless= you have cached CRL experience saying it's bad you have no reason to distru= st.=20 Also cryptographically signed data can be sent insecurely and be validated a= gainst change or tampering. Perhaps you are worried about privacy? Sent from my iCar > On Feb 24, 2020, at 4:15 PM, Job Snijders wrote: >=20 > Of course - in making strong statements like this one I can not afford > to assume I am right, so if you disagree - please tell me how I am wrong > (in detail :-) ). From nobody Mon Feb 24 15:29:26 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5FA3A1351 for ; Mon, 24 Feb 2020 15:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tecmx.onmicrosoft.com 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 2TR9Rl9CjirP for ; Mon, 24 Feb 2020 15:29:20 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760104.outbound.protection.outlook.com [40.107.76.104]) (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 929E13A154C for ; Mon, 24 Feb 2020 15:29:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lzR3YhobBGHiDRQD1k/fBnz9OyzRV4h5yg8Z4UR65ciGbXZzc5H9UTwCcAQcw+NYI1ra4ITQCu/x6l/Q2U9WAUZhiwjxIcqsE0UETzVyraS6WbGivpFrQawzqaX1qQ3JvaHEOjTaTKnNl32zaHNr4G6FL8K3eJKhyV2snY6gXWY8R6mMNBaxIorSQeQdSNzXgeZjWURH/rklZAxlJDMyO/j7nhN5F1susdN7HHcHZ+4kqRBTg0gKZTand8gDtHVFuwp0uRJVcDnPLCCh8F78ELNLsRsrByvjdOsXVm9lSViUEv7B0t9h011Wa9ucCYpJXM9n4JB/LxSyvdOzGIxCyw== 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=Sb4oIxzfUKmx8tmQM7eokiAWUsqcqAmw4gRH+Z0OCEk=; b=Ec+spdD9K+gZyL+6FfL5tVUPrLrKXwWaJ9rH8x73ZyO2X1q8PP5OYuUFBYHX9a6OhhWXsSn3/C7iXc2oCZ9VmeSHXteJ23yj4b/fDsaQ0rIciGpynT3ACaW8j+nZf0a4IPjr5PvE9w+Hhr12lBl4ALywU7YZhQ6Cy3PpJHT1x7TJlmXj7Sy0uIWh4par7TNeydJpYTCVn1cbSEB6hk9mKW7LHH92K2RfZl2uL/ksLqbzNs0Zkq9ASTQyLOpLrZIN0EiOkWMLvNgrwZQYYsg8jAi1nLOGuqdUHYxIgW0ee/Qa89FphDV5CfO0NhRa4zRD3+qQ7urF/Sdtmg3+Yb8azA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nic.mx; dmarc=pass action=none header.from=nic.mx; dkim=pass header.d=nic.mx; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tecmx.onmicrosoft.com; s=selector2-tecmx-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Sb4oIxzfUKmx8tmQM7eokiAWUsqcqAmw4gRH+Z0OCEk=; b=f6fTj3tYmlfJlU/yFysMUTFHdyQzhm3yAX2IcFU0T2kvNatoumimKM7KkQNd1ABDdcgdpaMwruIpc/1jHNbMRGh0JO4Ev27p7XU9FVWqgzbEiXGZ1UEdorVr9hto/E+gsXkPhkQdRSCMUUUn1/JWXp2SJTx2vXv8dpEhZ6ZUcYY= Received: from BYAPR05MB5141.namprd05.prod.outlook.com (2603:10b6:a03:96::13) by BYAPR05MB6536.namprd05.prod.outlook.com (2603:10b6:a03:e4::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.11; Mon, 24 Feb 2020 23:29:19 +0000 Received: from BYAPR05MB5141.namprd05.prod.outlook.com ([fe80::5150:4a0b:8d82:f39]) by BYAPR05MB5141.namprd05.prod.outlook.com ([fe80::5150:4a0b:8d82:f39%6]) with mapi id 15.20.2772.012; Mon, 24 Feb 2020 23:29:19 +0000 From: Francisco Javier Moreno Arana To: Job Snijders , "sidrops@ietf.org" , "claudio@openbsd.org" Thread-Topic: [Sidrops] what to do when the CRL is hosed? Thread-Index: AQHV6yVQn+r/EvWQc0CiGVvWf7UvM6gq2MyAgAAikyY= Date: Mon, 24 Feb 2020 23:29:18 +0000 Message-ID: References: <20200224151532.GD19221@vurt.meerval.net>, <20200224211531.GB60925@vurt.meerval.net> In-Reply-To: <20200224211531.GB60925@vurt.meerval.net> Accept-Language: es-MX, en-US Content-Language: es-MX X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=fjarana@nic.mx; x-originating-ip: [189.152.234.205] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 36294a0c-d2ac-4448-b146-08d7b9815eec x-ms-traffictypediagnostic: BYAPR05MB6536: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(376002)(396003)(39860400002)(346002)(366004)(199004)(189003)(2906002)(186003)(33656002)(45080400002)(7066003)(478600001)(6506007)(66446008)(71200400001)(316002)(5660300002)(52536014)(7696005)(9686003)(786003)(81156014)(966005)(64756008)(86362001)(66476007)(76116006)(66556008)(81166006)(66946007)(8936002)(66574012)(110136005)(19627405001)(55016002)(26005)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB6536; H:BYAPR05MB5141.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nic.mx does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ebLbeSBa3pEoWvOW/egnIJtRtclId0iWeDDqg7kebMWJdZ5tmckjnkuAKE3u0WwosHw+tJ8Qu0hCECJdOEzP9BoSKyuqqlaHTh7SIsFbSVflbeUBqWZdlB9fUclwJnOnjnbtRVTZuwuhfZ8t1zu6w3TQbxhQzkXcqhpj4AFiQNUyVGljUNLxmqYhmCGiSRX/ozgLu7RpLQ3/+0ZmgV2EOADlXFYvvT9oH5nfkKGzqhgJCZKF4NYCfD3TcmcNWuM3J+RV/4Yh7lV1rBcaRRq+pG2fyklJeXTwidOA6neV7ah4P5DBAVnAd80bmNpGeIXtuG7X8A102E5LFpKduX5KlXSyGh8ESM7ZMPahmsRDd/jEhJ6XzBsVw9zf2BFrGtZ6fFMEolvaYdsgLGKCmI3Oa/FuU5gbeQB/NkHlF4JYQ4UEklm97HMko8Vbyk5xn4VE7sgf/dTMokxlWP/IaUjDIB4b2ruM2t8JV70iKDxbpgXfI+gw2g83tMMzuKYCs3WtCzJg9HxR87dmlulvZRP44g== x-ms-exchange-antispam-messagedata: Fo8a0tsP/JKcbR3jkdb+jdGtNKR9FXSfJU3y2YwjEvBuOCtY0cJ+jkHcEU4tsv3Nwt5LMU+QTm2hmDu0ULn9FD+uo7iwjhIw6jkCWsPtXaoVm1gsS+9OJVBYWSRhN6SqA57aajINnYJolFUf1rbHxQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR05MB5141BE96C2699CDBDA45392CD4EC0BYAPR05MB5141namp_" MIME-Version: 1.0 X-OriginatorOrg: nic.mx X-MS-Exchange-CrossTenant-Network-Message-Id: 36294a0c-d2ac-4448-b146-08d7b9815eec X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2020 23:29:18.9605 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c65a3ea6-0f7c-400b-8934-5a6dc1705645 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8+/ByuIjE05OKN5qtN+b584j2qyIgcZWg2AkUTj8Q4iXZHjSYSbHETM0A6Pc/q8H X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6536 Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 23:29:24 -0000 --_000_BYAPR05MB5141BE96C2699CDBDA45392CD4EC0BYAPR05MB5141namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there, We had the same discussion (FORT validator dev team) a few weeks ago, since= the RFCs don't clarify the subject. Gladly, after reading this thread, we = can say that FORT is currently rejecting those CRLs. We've noticed the RIPE expired CRL and ~70k prefixes were rejected at that = moment. Regards, Francisco Moreno ________________________________ De: Sidrops en nombre de Job Snijders Enviado: lunes, 24 de febrero de 2020 03:15 p. m. Para: sidrops@ietf.org ; claudio@openbsd.org Asunto: Re: [Sidrops] what to do when the CRL is hosed? To reply myself: In case the CRL expired, or is otherwise somehow invalid; and the cache validator continues to consider the entire validation tree to be valid for some purpose, the validator is vulnerable to replay attacks because the use of unencrypted transport such as rsync (which supported in all validators, by mandate) give no support to trust anything anymore. I think ignoring the CRLs state goes against the entire RPKI trust-model mindset. A cache validator MUST consider the certificate have been appeared on the Certificate Revocation List (CRL) issued by the CA represented by certificate if the CRL is expired. While one can argue in different contexts of the application of X509 technology different (more forgiving) policies can apply; in the use case of RPKI I think we cannot tolerate anything less than to assume the CA has failed when the CRL is inaccessible or expired. And those running CA's will want to take careful note of this critical operational aspect. Cache validator implementations which didn't stop parsing RIPE NCC's tree today, should be aware they are have a security issue and consider how to upgrade their validation strategy. I think OpenBSD's rpki-client was the only one to get it right today. Of course - in making strong statements like this one I can not afford to assume I am right, so if you disagree - please tell me how I am wrong (in detail :-) ). Kind regards, Job On Mon, Feb 24, 2020 at 03:15:32PM +0000, Job Snijders wrote: > Hi group, > > It seems we need guidance and consensus on what to do when the CRL is > hosed in some way or shape. We have two implementation discrepancies pop > up recently: > > https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu= b.com%2FNLnetLabs%2Froutinator%2Fissues%2F274&data=3D02%7C01%7Cfjarana%= 40nic.mx%7C18b6558503814064281c08d7b96eb91c%7Cc65a3ea60f7c400b89345a6dc1705= 645%7C0%7C0%7C637181757516231674&sdata=3DM%2BMTjX2M%2BYYM3bsSr%2F%2Bgon= By6IKSAqaGU%2F4J%2BqlnZ%2BU%3D&reserved=3D0 > RIPE NCC's top level CRL expired this weekend > (https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= ripe.net%2Fsupport%2Fservice-announcements%2Frpki-infrastructure-issues&= ;data=3D02%7C01%7Cfjarana%40nic.mx%7C18b6558503814064281c08d7b96eb91c%7Cc65= a3ea60f7c400b89345a6dc1705645%7C0%7C0%7C637181757516241663&sdata=3Ds3%2= F6i%2BhO4bnqncsSj56ZpXDsulvgWUYA13Nm5%2BmnQiM%3D&reserved=3D0) > > https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flists= .nlnetlabs.nl%2Fpipermail%2Frpki%2F2019-December%2F000109.html&data=3D0= 2%7C01%7Cfjarana%40nic.mx%7C18b6558503814064281c08d7b96eb91c%7Cc65a3ea60f7c= 400b89345a6dc1705645%7C0%7C0%7C637181757516241663&sdata=3D8AHf2i8DNdTjl= U6TnGkbnkXK%2BLyIP%2FN3bnr0GlSZ%2B3E%3D&reserved=3D0 > > OpenBSD's rpki-client uses the x509 certificate validation functions > that come from libressl, which doesn't have a button to turn off only CRL > timestamp verification. I was told that some nasty code would be > required to work around that, so one can argue that rolling things by > hand in X509 handling rarely is a great idea. > > One could also argue that a softer landing is needed, unavailability of > the CRL should mean that only the CRL itself is not available and > proceed to validate the tree without the revocation list. I can see how > that is helpful in some circumstances. > > So, what to do? Whatever it is, ideally all validators follow a similar > process. > > Kind regards, > > Job _______________________________________________ Sidrops mailing list Sidrops@ietf.org https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fsidrops&data=3D02%7C01%7Cfjarana%40nic.mx%= 7C18b6558503814064281c08d7b96eb91c%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7= C0%7C637181757516241663&sdata=3DX8IkntXgxnt345fIIKgQEBc%2FpGuLzjtyiwa59= Bf2VMM%3D&reserved=3D0 Este mensaje contiene informaci?n confidencial y se entiende dirigido y par= a uso exclusivo del destinatario. Si recibes este mensaje y no eres el dest= inatario por favor elim?nalo, ya que difundir, revelar, copiar o tomar cual= quier acci?n basada en el contenido est? estrictamente prohibido. Network I= nformation Center, S.A. de C.V., ubicado en Ave. Eugenio Garza Sada 427 L4-= 6 Col. Altavista, Monterrey, M?xico, C.P. 64840 recaba tus datos personales= necesarios para: la prestaci?n, estudio, an?lisis y mejora del servicio, l= a realizaci?n de comunicaciones y notificaciones; la transferencia y public= aci?n en los casos aplicables; el cumplimiento de la relaci?n existente; as= ? como para la prevenci?n o denuncia en la comisi?n de il?citos. Si eres co= laborador o candidato a colaborador de NIC M?xico, tus datos ser?n utilizad= os para: la creaci?n y administraci?n de tu perfil como profesionista; el o= torgamiento de herramientas de trabajo; la realizaci?n de estudios; el otor= gamiento de programas y beneficios para mejorar tu desarrollo profesional; = la gesti?n y administraci?n de servicios de pago y/o n?mina; as? como para = contacto y/o notificaciones. Si participas en promociones o en estudios pod= r?s dejar de participar. Para mayor informaci?n revisa el Aviso de Privacid= ad. This message contains confidential information and is intended only for the= individual named. If you are not the named addressee please delete it, sin= ce the dissemination, distribuition, copy or taking any action in reliance = on the contents is strictly prohibited. Network Information Center, S.A. de= C.V., located on Av. Eugenio Garza Sada 427 L4-6, Col. Altavista, Monterre= y, Mexico, CP 64840 collects your personal data which is necessary to: prov= ide, research, analyze and improve the service; send communications and not= ices; transfer and publish your personal data when applicable; fulfill the = existing relationship; prevent or inform in the commission of unlawful acts= or events. If the data is processed in your quality of candidate or collab= orator of NIC Mexico, the purpose of treatment is to: create and manage you= r profile as a professional; provide you with working tools; conduct studie= s; grant benefits and programs to enhance your professional development; ma= nage and administrate payment services and/or payroll; as well as to contac= t you. If you participate in promotions or surveys you may stop or quit you= r participation at any time. For more information read the Privacy Note. --_000_BYAPR05MB5141BE96C2699CDBDA45392CD4EC0BYAPR05MB5141namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi there,

We had the same discussion (FORT validator dev team) a few weeks ago, since= the RFCs don't clarify the subject. Gladly, after reading this thread, we = can say that FORT is currently rejecting those CRLs.

We've noticed the RIPE expired CRL and ~70k prefixes were rejected at that = moment.

Regards,
Francisco Moreno
De: Sidrops <sidrops-bou= nces@ietf.org> en nombre de Job Snijders <job@ntt.net>
Enviado: lunes, 24 de febrero de 2020 03:15 p. m.
Para: sidrops@ietf.org <sidrops@ietf.org>; claudio@openbsd.org= <claudio@openbsd.org>
Asunto: Re: [Sidrops] what to do when the CRL is hosed?
 
To reply myself:

In case the CRL expired, or is otherwise somehow invalid; and the cache
validator continues to consider the entire validation tree to be valid
for some purpose, the validator is vulnerable to replay attacks because
the use of unencrypted transport such as rsync (which supported in all
validators, by mandate) give no support to trust anything anymore.  I<= br> think ignoring the CRLs state goes against the entire RPKI trust-model
mindset.

A cache validator MUST consider the certificate have been appeared on
the Certificate Revocation List (CRL) issued by the CA represented by
certificate if the CRL is expired.

While one can argue in different contexts of the application of X509
technology different (more forgiving) policies can apply; in the use
case of RPKI I think we cannot tolerate anything less than to assume the CA has failed when the CRL is inaccessible or expired. And those running CA's will want to take careful note of this critical operational aspect.
Cache validator implementations which didn't stop parsing RIPE NCC's
tree today, should be aware they are have a security issue and consider
how to upgrade their validation strategy. I think OpenBSD's rpki-client
was the only one to get it right today.

Of course - in making strong statements like this one I can not afford
to assume I am right, so if you disagree - please tell me how I am wrong (in detail :-) ).

Kind regards,

Job


On Mon, Feb 24, 2020 at 03:15:32PM +0000, Job Snijders wrote:
> Hi group,
>
> It seems we need guidance and consensus on what to do when the CRL is<= br> > hosed in some way or shape. We have two implementation discrepancies p= op
> up recently:
>
> https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.= com%2FNLnetLabs%2Froutinator%2Fissues%2F274&amp;data=3D02%7C01%7Cfjaran= a%40nic.mx%7C18b6558503814064281c08d7b96eb91c%7Cc65a3ea60f7c400b89345a6dc17= 05645%7C0%7C0%7C637181757516231674&amp;sdata=3DM%2BMTjX2M%2BYYM3bsSr%2F= %2BgonBy6IKSAqaGU%2F4J%2BqlnZ%2BU%3D&amp;reserved=3D0
> RIPE NCC's top level CRL expired this weekend
> (https://nam04.safelinks.protection.outlook.com/?url=3Dhtt= ps%3A%2F%2Fwww.ripe.net%2Fsupport%2Fservice-announcements%2Frpki-infrastruc= ture-issues&amp;data=3D02%7C01%7Cfjarana%40nic.mx%7C18b6558503814064281= c08d7b96eb91c%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C0%7C6371817575162416= 63&amp;sdata=3Ds3%2F6i%2BhO4bnqncsSj56ZpXDsulvgWUYA13Nm5%2BmnQiM%3D&= ;amp;reserved=3D0)
>
> https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flists.n= lnetlabs.nl%2Fpipermail%2Frpki%2F2019-December%2F000109.html&amp;data= =3D02%7C01%7Cfjarana%40nic.mx%7C18b6558503814064281c08d7b96eb91c%7Cc65a3ea6= 0f7c400b89345a6dc1705645%7C0%7C0%7C637181757516241663&amp;sdata=3D8AHf2= i8DNdTjlU6TnGkbnkXK%2BLyIP%2FN3bnr0GlSZ%2B3E%3D&amp;reserved=3D0 >
> OpenBSD's rpki-client uses the x509 certificate validation functions > that come from libressl, which doesn't have a button to turn off only = CRL
> timestamp verification. I was told that some nasty code would be
> required to work around that, so one can argue that rolling things by<= br> > hand in X509 handling rarely is a great idea.
>
> One could also argue that a softer landing is needed, unavailability o= f
> the CRL should mean that only the CRL itself is not available and
> proceed to validate the tree without the revocation list. I can see ho= w
> that is helpful in some circumstances.
>
> So, what to do? Whatever it is, ideally all validators follow a simila= r
> process.
>
> Kind regards,
>
> Job

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://nam04.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistin= fo%2Fsidrops&amp;data=3D02%7C01%7Cfjarana%40nic.mx%7C18b655850381406428= 1c08d7b96eb91c%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C0%7C637181757516241= 663&amp;sdata=3DX8IkntXgxnt345fIIKgQEBc%2FpGuLzjtyiwa59Bf2VMM%3D&am= p;reserved=3D0

Este mensaje contiene información confi= dencial y se entiende dirigido y para uso exclusivo del destinatario. Si re= cibes este mensaje y no eres el destinatario por favor elimínalo, ya= que difundir, revelar, copiar o tomar cualquier acción basada en el contenido está estrictamente prohibido. = Network Information Center, S.A. de C.V., ubicado en Ave. Eugenio Garza Sad= a 427 L4-6 Col. Altavista, Monterrey, México, C.P. 64840 recaba tus = datos personales necesarios para: la prestación, estudio, análisis y mejora del servicio, la realización de comunicaci= ones y notificaciones; la transferencia y publicación en los casos a= plicables; el cumplimiento de la relación existente; así como= para la prevención o denuncia en la comisión de ilíci= tos. Si eres colaborador o candidato a colaborador de NIC México, tus datos ser&= aacute;n utilizados para: la creación y administración de tu = perfil como profesionista; el otorgamiento de herramientas de trabajo; la r= ealización de estudios; el otorgamiento de programas y beneficios para mejorar tu desarrollo profesional; la gestión y administraci&o= acute;n de servicios de pago y/o nómina; así como para contac= to y/o notificaciones. Si participas en promociones o en estudios podr&aacu= te;s dejar de participar. Para mayor información revisa el Aviso de Privacid= ad.


This message contains confidential information= and is intended only for the individual named. If you are not the named ad= dressee please delete it, since the dissemination, distribuition, copy or t= aking any action in reliance on the contents is strictly prohibited. Network Information Center, S.A. de C.V.,= located on Av. Eugenio Garza Sada 427 L4-6, Col. Altavista, Monterrey, Mex= ico, CP 64840 collects your personal data which is necessary to: provide, r= esearch, analyze and improve the service; send communications and notices; transfer and publish your person= al data when applicable; fulfill the existing relationship; prevent or info= rm in the commission of unlawful acts or events. If the data is processed i= n your quality of candidate or collaborator of NIC Mexico, the purpose of treatment is to: create and manage your prof= ile as a professional; provide you with working tools; conduct studies; gra= nt benefits and programs to enhance your professional development; manage a= nd administrate payment services and/or payroll; as well as to contact you. If you participate in promotion= s or surveys you may stop or quit your participation at any time. For more = information read the Privacy Note.=

--_000_BYAPR05MB5141BE96C2699CDBDA45392CD4EC0BYAPR05MB5141namp_-- From nobody Mon Feb 24 15:35:03 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5273A1162 for ; Mon, 24 Feb 2020 15:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa 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 VX9UK8EyT6Hq for ; Mon, 24 Feb 2020 15:34:58 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on0628.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::628]) (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 662993A115E for ; Mon, 24 Feb 2020 15:34:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EwUSWQLMseafn77KLPtN84yerQqCMjUEueLTNdIsKKvRTFbAiRoW4JcRWTQUlcN64vvjePVdbRP93xU9CO1uletfPxOBP80xCn3dhwImvJPyGgnjUJbOSvXYtO7M/JjwMFuHu6GMnOa3rq7fge1KBq93xZZ00r84obKdcx33m0tVrT+cPkArqa6YIxY+5TaMX6r2ybnKRxm229TFj8O1AyTfBwxwiL/b1wOe26PX5WrAOInrjHTwpBlUoj6KLpuiXwyjaGbfcpJocVc2Q3VWBLkrjNI2wPY+b8M9UzEL3HqXtre43bwdvU09/u3SNt6UqBT5faCg3NanCsYD+c+M6g== 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=8ETEkCTNGVCPw+Z0okRj9TBc/CgFJ9yIUe5A4Ghb5OE=; b=WE4eeUn528qKjh7bZ30npIBuq7A/XfOHWCaPMq3hhu/v+PTOCNJiZg6ktPLZuOaCfbtPRWngBIZcOzn5J2pky8q5nI37JCzSDTH8r3YGoJFYmKhqKGJ2abcAo3DlkroR1sq3VrdwJ8vPUhEUc2m9jKZ+W3ApvWZn3Vf29p9ZA2sHj8z9ABFUZgZNryVegnZEQ04kmPNmA6DSXwLu6arIa2ZWG6Cs69XqPuOSCXROyaXAN8L828cCYaHEgrcQQhjy95T1gbB8zFbk3MeZPTl7GmjJM7gP+rn4yKTXDOQgfa77yQ6sTD5zbmE8oqOcKImyBJQ5EcbTqMAcL/wEMHGqqg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8ETEkCTNGVCPw+Z0okRj9TBc/CgFJ9yIUe5A4Ghb5OE=; b=HgnuYI0JOfViqLdkP36Sq3sYx6K/XSP1VcVUBVCtQNlP1fxx2f0buMHT7IiUHpgs4FWPgPg+Blh8DUtTYfwlZAy8Xno3EICTPhqZLzU6FYMbcNEUlUgwLx8Sa8DMBQbDTH/t02uLukaSy0BfA1RFN+98nuPttwbeVAon6Ukg1jE= Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM (52.135.56.21) by AM7SPR01MB0005.EURP190.PROD.OUTLOOK.COM (10.141.189.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.17; Mon, 24 Feb 2020 23:34:53 +0000 Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::acf9:986c:23f6:da2f]) by AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::acf9:986c:23f6:da2f%5]) with mapi id 15.20.2750.021; Mon, 24 Feb 2020 23:34:53 +0000 From: Ben Maddison To: "job@ntt.net" , "jared@puck.nether.net" CC: "claudio@openbsd.org" , "sidrops@ietf.org" Thread-Topic: [Sidrops] what to do when the CRL is hosed? Thread-Index: AQHV6yVOp0IS38hLHU+bnXCKrcyzWKgq2MyAgAAR5ICAABUKgA== Date: Mon, 24 Feb 2020 23:34:53 +0000 Message-ID: References: <20200224211531.GB60925@vurt.meerval.net> <10259FC6-FE65-4B34-81B2-A37FCFA29BF2@puck.nether.net> In-Reply-To: <10259FC6-FE65-4B34-81B2-A37FCFA29BF2@puck.nether.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=benm@workonline.africa; x-originating-ip: [160.119.236.50] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 70a0cdf0-130e-4419-5b0f-08d7b982264a x-ms-traffictypediagnostic: AM7SPR01MB0005: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400004)(136003)(396003)(346002)(366004)(376002)(189003)(199004)(91956017)(5660300002)(76116006)(2906002)(4326008)(66556008)(66476007)(66946007)(64756008)(66446008)(86362001)(6506007)(6512007)(71200400001)(508600001)(6486002)(8936002)(54906003)(316002)(110136005)(81156014)(81166006)(8676002)(53546011)(26005)(186003)(2616005)(46492005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7SPR01MB0005; H:AM7P190MB0583.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: workonline.africa does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: t0KeMQwuV0NuR4Nip9BOyY+Hxd0d9lHNMVZtwZjgGzNjc3pHe/7ChrZ9qsYAFPA7vsPr2LtXFxAFEM6yzXuxANb1HpNoUJHFlZrrP5/m4tonaElNJuU021Zxi7wM/vwY0vkxab8vCeordAxDIaPtAz3CIQXVQhbGfyYLARPDwSxmT4YE4xk0ETlnnT0kfVcvqp54rd4vQbi9jJsJ+NNis7GvXNLWG8ho/hOvhxPD5VgycBOExCJh84W37viARV3RLoh6gPd0NAbt3kZhz2YLnNlFzzUOTmF9ODKjy3Zz9p0o5Zdl3ZZOxu5iQi3YyYWSozC688BKHriqQbEVgyHtRgZBhr7RHcTQrDWOICmer3RsnIEw2MXzUIRP00zUAz5BqxoqipINj1wD/jPRK74ZOtrdwc8wPbGUoF0I76Hx9mqcHjI88JtN1bcj5Exv5aTyQt2V56g4m1uoC4iu0PvHSNwwGfxzTT0fiH5Z6EtcWPrxHb1wIaYecPgzr2WfSb2e x-ms-exchange-antispam-messagedata: gSI/yPGNsiPb+WejFdjErId8iUGGLDxB8NI4TGfifrUQkzt5oXVR+Rl0g98yL8c0tNIL5/W1jrqAMdhaEDBPIxf+w3H97oAWryPAHR6gqbql1enqQR6wUK1Sp2T5/jb3e9352lOmnfQxb4N3NY7/sA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 70a0cdf0-130e-4419-5b0f-08d7b982264a X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2020 23:34:53.5239 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mMPI4cqXJQnvRx/ky9n6rFWmZQt47Yq9Lmu9tAq9aOAl7hgxPS1yTf1Fj1+de2ho23gNDzzaMb5n+GLwxFg85w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7SPR01MB0005 Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 23:35:02 -0000 SGkgYWxsLA0KDQpPbiBNb24sIDIwMjAtMDItMjQgYXQgMTc6MTkgLTA1MDAsIEphcmVkIE1hdWNo IHdyb3RlOg0KPiBJIHRoaW5rIHlvdSBtYXkgYmUgcmlnaHQgaW4gYWJzb2x1dGUgdGVybXMuIFlv dSBhcmUgbGlrZWx5IHdyb25nIHRoYXQNCj4gdW5sZXNzIHlvdSBoYXZlIGNhY2hlZCBDUkwgZXhw ZXJpZW5jZSBzYXlpbmcgaXQncyBiYWQgeW91IGhhdmUgbm8NCj4gcmVhc29uIHRvIGRpc3RydXN0 LiANCj4gDQo+IEFsc28gY3J5cHRvZ3JhcGhpY2FsbHkgc2lnbmVkIGRhdGEgY2FuIGJlIHNlbnQg aW5zZWN1cmVseSBhbmQgYmUNCj4gdmFsaWRhdGVkIGFnYWluc3QgY2hhbmdlIG9yIHRhbXBlcmlu Zy4gUGVyaGFwcyB5b3UgYXJlIHdvcnJpZWQgYWJvdXQNCj4gcHJpdmFjeT8NCj4gDQo+IFNlbnQg ZnJvbSBteSBpQ2FyDQo+IA0KPiA+IE9uIEZlYiAyNCwgMjAyMCwgYXQgNDoxNSBQTSwgSm9iIFNu aWpkZXJzIDxqb2JAbnR0Lm5ldD4gd3JvdGU6DQo+ID4gDQo+ID4gT2YgY291cnNlIC0gaW4gbWFr aW5nIHN0cm9uZyBzdGF0ZW1lbnRzIGxpa2UgdGhpcyBvbmUgSSBjYW4gbm90DQo+ID4gYWZmb3Jk DQo+ID4gdG8gYXNzdW1lIEkgYW0gcmlnaHQsIHNvIGlmIHlvdSBkaXNhZ3JlZSAtIHBsZWFzZSB0 ZWxsIG1lIGhvdyBJIGFtDQo+ID4gd3JvbmcNCj4gPiAoaW4gZGV0YWlsIDotKSApLg0KPiANCkkg dGhpbmsgKHN0cm9uZyBub3QtYS1jcnlwdG8tZ3V5IGRpc2NsYWltZXIsIGV0YykgdGhhdCBKb2Ig aXMgcmlnaHQuDQoNCkNvbnNpZGVyIHRoZSBjYXNlIG9mIGEgcHJpdmF0ZSBrZXkgY29tcHJvbWlz ZSB0aGF0IGhhcyBiZWVuIGRpc2NvdmVyZWQNCmFuZCB0aGUgY29ycmVzcG9uZGluZyBjZXJ0aWZp Y2F0ZSByZXZva2VkLg0KQW4gYXR0YWNrZXIgd2l0aCBhY2Nlc3MgdG8gdGhlIGtleSBjb3VsZCBN SVRNIHRoZSBob3N0aW5nIHJzeW5jIHJlcG8NCmFuZCBzZXJ2ZSBhIHN0YWxlIENSTCB0aGF0IHBy ZS1kYXRlcyB0aGUgcmV2b2NhdGlvbiwgYW5kIHRoZXJlYnkNCmNvbnRpbnVlIHRvIGNyZWF0ZSB2 YWxpZC1zZWVtaW5nIFJQS0kgb2JqZWN0cyBvciByZXBsYXkgb2xkIG9uZXMuDQoNCkkndmUgaGFk IGEgcXVpY2sgc2NhbiBvZiByZmM1MjgwLCBhbmQgSSBjYW4ndCBzZWUgYW55dGhpbmcgdGhhdCBz YXlzDQp3aGF0IHJldm9jYXRpb24gc3RhdHVzIHNob3VsZCBiZSBhcHBsaWVkIGJ5IHRoZSB2YWxp ZGF0aW5nIHBhcnR5IGVpdGhlcg0Kd2F5LiBQZXJoYXBzIEknbSBsb29raW5nIGluIHRoZSB3cm9u ZyBwbGFjZT8NCg0KTXkgaW5zdGluY3Qgc2F5cyB0aGF0IGFuIFJQS0kgY2VydCB0aGF0IGhhcyB0 aGUgQ1JMIERpc3RyaWJ1dGlvbiBQb2ludA0KZXh0ZW5zaW9uIHNob3VsZCBiZSBjb25zaWRlcmVk IHJldm9rZWQgaWYgYSB2YWxpZCAoaW5jLiB1bmV4cGlyZWQpIENSTA0KY2FuJ3QgYmUgcmV0cmll dmVkIGZyb20gb25lIG9mIHRoZSBsaXN0ZWQgZGlzdHJpYnV0aW9uIHBvaW50cyAob3INCnRocm91 Z2ggc29tZSBPT0IgbWVhbnMpLg0KDQpDaGVlcnMsDQoNCkJlbg0KDQo= From nobody Mon Feb 24 15:43:31 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BD53A159E for ; Mon, 24 Feb 2020 15:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=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 C4sV9lAJMwNL for ; Mon, 24 Feb 2020 15:43:28 -0800 (PST) Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2FA83A159D for ; Mon, 24 Feb 2020 15:43:27 -0800 (PST) Received: by mail-wm1-f51.google.com with SMTP id s144so969118wme.1 for ; Mon, 24 Feb 2020 15:43:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=nEKnTOCea8njKTuL5sKNMmlVpIe/GqOtOFBHvqi6DpE=; b=ZaqWyvRQw8UQf6g2AJX2I+jEF0aEhWIQ/qiW3b0sRUGgzpYijP6nXnFshoraryOLqt fksSYzLiuAeHfKXIBhCgY2OIj1wRt9KatvcFYyqSqRbD3MXG4PIGiXihBRi6QcsHkQbu IZBHVGImA2vEyhW5Rpa+6k05vYCiLqMIEs/g3P16eMqkrCI1fy2JgKTzMpiYeAFqZUfe vbwtoBrS8HwTBMENz09ppDIg4vcxB5PxCpyEkNHcXDGE/v8hplhzhOsspJpv+z3G584k h49ux/M4q1rvTdAkxE/84YjOSVxghAV3sY40FWG5BPxbBF1YTmp2SOqychthQjrkZ4DE +ELA== X-Gm-Message-State: APjAAAXwjZMRh/OMYU0o2NPzmydAXaYkzXBdXd/8YghUixNY3a8DjelA Sq73QSglv+QT3OE2mmno4NnMNQ== X-Google-Smtp-Source: APXvYqx6Q1wZSLWORKuWj1ZPsBfMJ0QH83HHPKjZb52/3YWHgH/84o0zqI79xV5NGsZnt377RZXe9A== X-Received: by 2002:a05:600c:2254:: with SMTP id a20mr1383379wmm.188.1582587805884; Mon, 24 Feb 2020 15:43:25 -0800 (PST) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id n5sm3928793wrq.40.2020.02.24.15.43.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Feb 2020 15:43:25 -0800 (PST) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 916c22fc; Mon, 24 Feb 2020 23:43:24 +0000 (UTC) Date: Mon, 24 Feb 2020 23:43:23 +0000 From: Job Snijders To: Jared Mauch Cc: sidrops@ietf.org, claudio@openbsd.org Message-ID: <20200224234323.GC60925@vurt.meerval.net> References: <20200224211531.GB60925@vurt.meerval.net> <10259FC6-FE65-4B34-81B2-A37FCFA29BF2@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10259FC6-FE65-4B34-81B2-A37FCFA29BF2@puck.nether.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 23:43:29 -0000 On Mon, Feb 24, 2020 at 05:19:33PM -0500, Jared Mauch wrote: > I think you may be right in absolute terms. You are likely wrong that > unless you have cached CRL experience saying it's bad you have no > reason to distrust. CRLs in RPKI != CRLs in TLS/browser context. > Also cryptographically signed data can be sent insecurely and be > validated against change or tampering. Perhaps you are worried about > privacy? I don't think I'm concerned about privacy. My point was that in the application of X509 in the use case of RPKI: if the CRL is expired, you have more than enough reason to distrust. Kind regards, Job From nobody Tue Feb 25 00:03:49 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24F23A099D for ; Tue, 25 Feb 2020 00:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 1Gexkf7hkxGI for ; Tue, 25 Feb 2020 00:03:46 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 51B373A0999 for ; Tue, 25 Feb 2020 00:03:45 -0800 (PST) Received: from glaurung.nlnetlabs.nl (DSL01.212.114.251.79.ip-pool.NEFkom.net [212.114.251.79]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id CB31929E01; Tue, 25 Feb 2020 09:03:41 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Tue, 25 Feb 2020 09:03:38 +0100 From: Martin Hoffmann To: Job Snijders Cc: sidrops@ietf.org, claudio@openbsd.org Message-ID: <20200225090338.10464b1a@glaurung.nlnetlabs.nl> In-Reply-To: <20200224211531.GB60925@vurt.meerval.net> References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 08:03:48 -0000 Job Snijders wrote: >=20 > Of course - in making strong statements like this one I can not afford > to assume I am right, so if you disagree - please tell me how I am > wrong (in detail :-) ). Let me counter with a different strong statement: In the context of RPKI, CRLs offer no additional value and can safely be ignored. The reason is the manifests. Unlike CRLs which only say "these certificates are not to be considered valid anymore", manifests say "this is the complete set of objects currently issued by this CA". They also refer to concrete objects, identifying them both by URI and a hash over their content. This is a much more powerful mechanism than CRLs. What=E2=80=99s more, they offer a soft and a hard deadline for validity. Th= eir next update field is a soft deadline, much like with CRLs. But there=E2=80= =99s also a hard deadline in that the certificate they=E2=80=99ve been signed wi= th expires eventually. While the former has the same ambiguity as the next update field of the CRL, the latter doesn=E2=80=99t. If the manifest is expired, the CA is basically gone. Further, the CRL is included in the manifest. So you can=E2=80=99t even rep= lay an old CRL without also replaying the old manifest. Essentially, no information conveyed by the CRL isn=E2=80=99t also conveyed= by the manifest. The CRL solely serves to provide additional complexity for the code generating and validating RPKI objects and, apparently, creates ambiguity in the interpretation of the specification. Kind regards, Martin From nobody Tue Feb 25 06:13:41 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA323A0D9F for ; Tue, 25 Feb 2020 06:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 b0xove5Nlh0C for ; Tue, 25 Feb 2020 06:13:38 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 629FA3A0D9E for ; Tue, 25 Feb 2020 06:13:38 -0800 (PST) Received: from allealle.ripe.net ([193.0.23.12]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1j6axt-0000T2-1q for sidrops@ietf.org; Tue, 25 Feb 2020 15:13:37 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::2f6]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1j6axs-0008PF-Vj for sidrops@ietf.org; Tue, 25 Feb 2020 15:13:37 +0100 From: Nathalie Trenaman Content-Type: multipart/signed; boundary="Apple-Mail=_7E77EFEF-2E4D-4314-B938-E836F80727EC"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Tue, 25 Feb 2020 15:13:36 +0100 To: SIDR Operations WG X-Mailer: Apple Mail (2.3445.104.11) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a65282a590c9abce232429f60e76d53eb Archived-At: Subject: [Sidrops] RIPE NCC RPKI Outage Post-Mortem X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 14:13:40 -0000 --Apple-Mail=_7E77EFEF-2E4D-4314-B938-E836F80727EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear colleagues, =46rom Saturday 22 February at 08:24 (CET), any newly created, modified, = or deleted ROAs (176 in total) could not be added to our publication = server due to a disk problem. =46rom that moment on, all the data was = stored on the database, but the publication did not happen. The disk did = not report any problems and, therefore, no engineer was alerted of this = incident. Due to the disk problem, starting from Sunday 23 February at 09:10 = (CET), our CRL expired and our repository could not be properly updated. = This was reported to us on Monday 24 February at 11:44 (CET). = Immediately, our engineers fixed the disk problem, however, since the = CRL expired, all underlying objects also expired. Depending on the = Relying Party software an operator used, this abnormal behaviour = appeared differently. Initially, our engineers tried to do a full re-population of the RPKI = repository, but unfortunately, this did not update the CRL in the = validation tree. At 15:03 (CET), we performed a full CA key-roll, which = was completed at 21:02 (CET) and resolved the problem. At 19:58 (CET), = all objects in the backlog were published. We apologise for any inconvenience this may have caused and we are = taking all the necessary steps to ensure this incident does not appear = again in the future. Kind regards, Nathalie Trenaman Routing Security Programme Manager RIPE NCC --Apple-Mail=_7E77EFEF-2E4D-4314-B938-E836F80727EC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEErOQRhE+jh6+GVH8pAwRJ2YYkN2oFAl5VK5AACgkQAwRJ2YYk N2r4kw/+IBEPpMN/Fj4P+R2QY9jE5VOpLL2rxz1T5eG2/TSUZ4nuuCKUmDodvvqy QBQLzebwld+n1H/eJOhvAvDtouGo4XJuweCt2hF7T1Izpt8iiQVJNAT6kwkXYBkQ om/du25U2wqGw/h3MP02oSvRu4U659sXqFiIHJmGEcXUO+lxqfelNiSk7SpzdkY/ yZtNNhrsfOFJQhQvivirBuNfRv2cByIL2+3plGXCwvwkLBTRzjNQ5MCpw6S4U/uz NsBMpmFp99Et4myRSSHRougtWXQjiOMwTo8StDDzarPrAlsEdpyFid0lm9Hb0wLx 3aHADeFIhnMhBBuso8jotm0OAtYgfxOU3ccGXu61LP1yetAbmCtxuIQtnv9MeQKU /WFpUbBUbR6HEKjHdAcgAwZO8LcIzvqqu0Dg0b7slapHZRiYaVVYUTsqORaMfgTy D+tvO3uvt9AWmNVNXlC3WpccjK0IJs4iNAjS6/nyRhCWopegwpXLWKz98LSHUKui 9js2H08TO7NoAzpSUQcFMiwVr7QunPgJlUAvodE/XL/j02ASIPPs/p0wxElr/ocI DIV5GtJSrKYoVr9+dCIriiMAHL2X/bogAkwvGhT0D1V+D4xYyYjyY8V72nCZglk5 ao0qqMjevlTXd+pIfAIXlGts+fVF7NgE19vAP0zW2uwwYyE3nqY= =Me+m -----END PGP SIGNATURE----- --Apple-Mail=_7E77EFEF-2E4D-4314-B938-E836F80727EC-- From nobody Tue Feb 25 08:56:06 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03073A1067 for ; Tue, 25 Feb 2020 08:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=verizon.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 MMPAMO79LbFa for ; Tue, 25 Feb 2020 08:56:03 -0800 (PST) Received: from sonic311-14.consmr.mail.bf2.yahoo.com (sonic311-14.consmr.mail.bf2.yahoo.com [74.6.131.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B391B3A106B for ; Tue, 25 Feb 2020 08:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1582649762; bh=Ifw3k6n4WeQhoXRqouwRep4XRf8SW270DF6nQuZxUU0=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=eVUaUaEBRs9L8g6tVgVUqoe70a5ipImruHOAHHGRqnYvMCKIcBMdz99L2s2ng3C5ENPd1SI/RSIrFiYGLEv+fqyKGq6YvhZgYxO+KnKVCdBz4KJO325t4LrGlBWgHL3ofCGprtS0wX2joNkos9FXZ16rO0aWO5SmzFW75c94RO4gwe9LUcQLUEr2QJ/pwEqjdOICqrx1Cf5XBzYEWXbUFZalpvwbEtUeuHRc7C37tDrF5TUMjipd9MFEir9rj+FcSNvDPf+0O+8w/8OsvUTcw6k3eruhJ4MF3jRiO+sI64QMZH1g7bbV0fe8uzN2G4pxwyDbimrWQ7C5DRI92B/Jbg== X-YMail-OSG: Fqunmi8VM1mSSIbbOwE7M_mk7PmztgRL6fT6NLLeyivr2DgA2F661HLC6Utsjrg W5ylYZc.br7s06MQC1vxKWIgFG3uCDbMQjukVPBxkGWJQlEB1_7ua2n9m06.FcCiEc1orjDoWRXJ aqBciOk.FXIRAht4L1Wh403VY_N0I9UFfpnk2j9ETTcbhNynNka0dC8uzjmfyKToGl9I1C415ERu 1jsB0cuwrnBGbCa8YtOLn9ilVbgitxpVQnrv3Te00xN74eAba3X8dTallceVjDz_5pW7kpRgu3iR zsfC55RvuuRXD8Gi0hsdXuLj_WeWDytly81X_u31nmjCx6rktLMsE0S7WyOJDMYu.H7Ca4Hdhwai S.eiVNL4P8RVID75MKGrblI_omgFVwntIyYp9gB2KDfDE_dMPtatf18eNmY4Ygfz8MwOqEcFot5W CozM5jSBQqRN_pdLObAkfpojeQNF2KG7Z9hIxVoYAuLmv9DgIwEugceHs4ih7FfrhMNnFZJ4apwG CgjY0ZJ5LaKNOjmPgC5K_MTPM0StjvGyYAJtErgCntos2uW9wfeQzwFOc6hY_JO6AN3b8ZyAq9gC ieUIQGMe1QYkCsuBK.sGeDdrds0AL6qT87PesSX25JurT_Ul9wdH0LRtGEwrPthfV6ea0yT39uv4 tnxdtv1yUt.vNh73Hik6_rqGoQ9b9p6Od74jPtuu5B3jBnsaHNddQFOrW3ITCommAmTo9Zp2O77h tQG7nayKMx.6yUcpETpTmQQ5M8065pCWqVgZnA6RyEb6vMsw.ZikxASxbZ65dBCKhukivTOHjgrs jyOobieLUvMnnSPE8Y_sysUDGFllM8ip4vd__2e0EsyXCbw.OD8PJ_cVuq_wabPJ6eqghep.to6v ydgseAZ11biP.iRQg60IwPL1L48ObOjq1CsTf7B.YSXoRQ2C_tCxE.SUH3UvEpCKTBryOB9SiofY XXN_HRxUG00rsa8eHQg2msC21Bcu8xxV35gVOt_BAngCv5P43.LXz0mOSTTBmOKbxcKt9ttnYPob Gwd7smnMuFEDD1yjG1QMoFZVcQaisj3Xx3Fiey9bMo_A3R0YmnTOKT455bvsAVGxrhE3Q8dPR2FR Xz5M.3QBrXTwbBtnz21ixXyGmyJLoyt.Hr2y5BdQj0ZUVNzXqWS_It1sYhl.qkFpm.7uB7498EWY eQvRXgh2vgICjoWrvS2PBrb3f3JdNnM6Qg7ylBsfb9VW_d5b7p3cW2xTQZN_344Ma5vLdRvpy5kG aAZR2ff1SgDwXOSLoz0VOoPmxLkKR4IrO4N9gvt92wb8feMdQOhXniKGyg64gqoaClTnPyHymEZ6 5asV4l87HJCt7uNmqzk2etfF.SVuWNc1c.HTPd9t6vnnzDGn3jaDXzikMmSZtH8kRmfQQvMS3l6S 9E0v_iPFdQta0Av964gpi0sWXG7z19FG0eYXa_Zu4HvzHljxbCrI- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Tue, 25 Feb 2020 16:56:02 +0000 Received: by smtp406.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9e30ce8293df2f04dc4a561a7e50866f; Tue, 25 Feb 2020 16:56:00 +0000 (UTC) To: sidrops@ietf.org References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> From: Stephen Kent Message-ID: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> Date: Tue, 25 Feb 2020 11:55:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200225090338.10464b1a@glaurung.nlnetlabs.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.15302 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 16:56:05 -0000 Martin, > Job Snijders wrote: >> Of course - in making strong statements like this one I can not afford >> to assume I am right, so if you disagree - please tell me how I am >> wrong (in detail :-) ). > Let me counter with a different strong statement: In the context of > RPKI, CRLs offer no additional value and can safely be ignored. I disagree. > The reason is the manifests. Unlike CRLs which only say "these > certificates are not to be considered valid anymore", manifests say > "this is the complete set of objects currently issued by this CA". They > also refer to concrete objects, identifying them both by URI and a hash > over their content. This is a much more powerful mechanism than CRLs. As a co-author of the manifest document I can assure you that these objects are not intended as a replacement for CRLs. To provide analogous functionality one would have to interpret the absence of a cert from a Manifest as evidence that it was revoked, or expired. There is a lot of experience in the broader PKI community that suggests Subjects are sloppy about expiration dates for certs, and some evidence that CAs are not much better :-). > What’s more, they offer a soft and a hard deadline for validity. Their > next update field is a soft deadline, much like with CRLs. But there’s > also a hard deadline in that the certificate they’ve been signed with > expires eventually. While the former has the same ambiguity as the next > update field of the CRL, the latter doesn’t. If the manifest is > expired, the CA is basically gone. I don't agree with the reasoning above. It's true that the cert used to verify (not sign) a Manifest will expire, but so will a CA cert. Why do you think that a CA will be better at maintaining a current Manifest vs. a current CRL? F or most RPKI CAs the trigger to generate a new Manifest will be the need to issue a new CRL (because many CAs have elected to issue CRLs on a daily basis). > Further, the CRL is included in the manifest. So you can’t even replay > an old CRL without also replaying the old manifest. The discussion (in 6486) of what an RP should do when a current Manifest is not available, or when there are some discrepancies between what  the Manifest says and what has been retrieved allows for a lot of local policy discretion. As a result, an RP might well accept an old CRL and corresponding Manifest even though the Manifest appears to be stale. > Essentially, no information conveyed by the CRL isn’t also conveyed by > the manifest. The CRL solely serves to provide additional complexity > for the code generating and validating RPKI objects and, apparently, > creates ambiguity in the interpretation of the specification. I disagree. Steve From nobody Tue Feb 25 16:24:05 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B373A096A for ; Tue, 25 Feb 2020 16:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=algebras-org.20150623.gappssmtp.com 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 VRWsVaoKmBxy for ; Tue, 25 Feb 2020 16:24:02 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4CE3A0967 for ; Tue, 25 Feb 2020 16:24:02 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id p8so794773iln.12 for ; Tue, 25 Feb 2020 16:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UM6OfXIKUz/s1555DuAckJ3dImdpwrvVMgIGEXhsDHg=; b=gySvRNgi2D1hGoffWrrQaEpLY5NKQdfQRfBBV2hjYCFXABsT93kdLuyyFKiX5aBFWL 405xhRhHEyDONiv8MQ2MZlzCoaGyxlstKe+vI0a6lumEo0AqtdJiHbhLCszxde1ZfTlR qyBXhuQ0lZby2dmVupOMD7yj7OEFJPOTDdiXvhq05Se3N7TY3AYJtNgNCToHrVeoTCd2 kpcl0H7tOhQn8Vino03CIiAGLvUp9kJ1+SY2/49cUucDHSMf0EV/Eu6/if3y/bh2UzGp Qm261PfYe37TE3LzmWF9e1qZTc8mE+G2oCyzzRp9Gr0rdfQ1DxwdkvY62lJf06F/j9kk gRjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UM6OfXIKUz/s1555DuAckJ3dImdpwrvVMgIGEXhsDHg=; b=ObKsmQ6Opp2gN882uHdzMeiE0GfUSbZXHp6vOheJ2C+JqN+HmBR0yPjMxkvBsHoNsy pN4nEvxqzT7uv/otxKZPWKAbaDMFnrKQKtoXkRVGjQI/Fzb3FDXVPelgm75BojMB2xTi TuRzgLvRqQji7dnoS7ohQ7drEphRLeq1+9JPxfv6yy6Q5vAqPw9FKeKNGlPG9LQ9TAjH SQ2dFj1qtr5Sr4VJuxPQvXyiubTKADkrqH323mKY6igoa0csYXyUEnawk3/Du90b+wK0 D4HsHRDpzn+ONHcTEF+nvq8sgEYbc24ksoV8GhI4Wu140B0QHARlC76KyFUlFEomdyZl KIRQ== X-Gm-Message-State: APjAAAVgyxLDbCGpHwSt17nRBCSYYaryOQ6d3jfRhK5JLUtkfIpab37+ meZsCpQ1RbxVO5Jfxi3FGXd6OpuJz9WJFxqfO8sntEPH X-Google-Smtp-Source: APXvYqyU5l3obXpVUjeu+kSYyOnRwoMnD4RQbDPHEBIt296w4uXhssNrPEIbae+QxWDWlh3TcFRFkG6yTbtAbcVBJHk= X-Received: by 2002:a92:5d88:: with SMTP id e8mr1409007ilg.106.1582676641326; Tue, 25 Feb 2020 16:24:01 -0800 (PST) MIME-Version: 1.0 References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> In-Reply-To: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> From: George Michaelson Date: Wed, 26 Feb 2020 10:23:50 +1000 Message-ID: To: Stephen Kent Cc: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 00:24:04 -0000 I believe while I may use sloppier language, in broad intent agree with Steve. There is information in a CRL which is not expressed in a manifest. We added manifests to our system, we did not deprecate or replace CRLs. We did not design this PKI with intent to make CRL optional or unnecessary, and the Manifest as I understand my recollections, was to provide a statement of what MUST be seen, not to exclude any other things existing, or to repudiate things. it is not "complete" as I understand it, it is only a statement of things which should not be missing. There can be other things. it is entirely possible publication of the manifest is asynchronous to other publication events, (large flat repositories) and so will not reflect fetch state, but future manifest state will. It is a mechanism to show if intermediates are attempting to hide things. It is not a categorical statement that other things are invalid or valid, because they can be cryptographically valid, not expired, but repudiated by a CRL which you are not seeing. If you cannot see a CRL which you are told should exist, to assume the CRL doesn't matter feels extremely unwise. I may have mistakenly published entirely cryptographically valid things which do not now inform my intent, and I have tried to repudiate, and you cannot see that repudiation and now interpret states of routing in ways which do not reflect my true intent. -George From nobody Tue Feb 25 18:02:23 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD3C3A08DC for ; Tue, 25 Feb 2020 18:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.587 X-Spam-Level: X-Spam-Status: No, score=0.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.663, MISSING_HEADERS=1.021, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6hTQC2agW3Ck for ; Tue, 25 Feb 2020 18:02:19 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6265F3A08D9 for ; Tue, 25 Feb 2020 18:02:19 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id r19so1143176ljg.3 for ; Tue, 25 Feb 2020 18:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=OVn+h8Qhs0xrhn1g7HTj7LBNcdYRZkGk7fiw8g3OJ98=; b=UQRhckGj599/yogD3l1ganG+WdpWh1VHpRCBg+f0u3cx6f48ZWFk2AC6WCqBI+cMXe Znk9pyRNG5MRReVopSfPmxHUl37Bh6L/QjdunS8pORWlkG14TX2UUg/UFxuHiUFm//Ln LoyEjg1o+NWPxdsSw4Nh7zLYS0WtS/CVmv5nQKfo0RrmD74emiWvKOoCOYemmkr4YK3o rx4RgdSqeQXWyolQWJxsqdGH6JyNdGUyblrzCoKx6c4gKW2V88p7cMugjwvvIqpQqc+P jEnGLg+/mDztbdhiC8fNY/3ovTE2dwQZC2aqdO0s/6iP7PHYW70621u1E+NYBMMPvX1Y Jjcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=OVn+h8Qhs0xrhn1g7HTj7LBNcdYRZkGk7fiw8g3OJ98=; b=F1abQ/m+B5yTojuzV+FA6kcyR8bRoJDnJOS+nAwW5lzcTrnuYMpVkwsm+1vO31RN6t 7fxdXwikyTrA9XCjO7hqgKLFfe0/CW6SRz2yr3acjwemBQFXrf46TzQlvTyjx1KcEOw1 kJT2WOGyfidwCdoYf4uIN8wyO0wyilJBIOKxQKdM7YiahgaN+HOnPYOuxrvhydfyuQ3C zfkZhgxQGGr+eQTERJIUvlAV3A2hC2S1nqjtjgmuTitIpaoayqaxPWGbKUUFT9cBVifF azNBxg+UtZRtxNqucNcNufZbqlpW5ueJjG7+1jM2Tu5B1y+D4IEdR9b4UmFZBZdeaPGC JCOg== X-Gm-Message-State: APjAAAWECxcDWEXD52aSk1cx8gPC9Qp6kp6TSYCkbJ5OhTazjYX8AcAO ayxlhbQaBGyt+YZY7AiRkRpCFBpJgu7eRj7sudsvQ7oa X-Google-Smtp-Source: APXvYqxtApSEi0ghJ7/KjPS0XvW4tV7xi6ioIC+KUKWqxX66nx2HhdyU9UQt21EwU7SiABp7Oqd1EC6nN92Lq+NXcE0= X-Received: by 2002:a2e:96c6:: with SMTP id d6mr1223634ljj.4.1582682536986; Tue, 25 Feb 2020 18:02:16 -0800 (PST) MIME-Version: 1.0 References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> In-Reply-To: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> From: Louis Poinsignon Date: Tue, 25 Feb 2020 18:02:05 -0800 Message-ID: Cc: sidrops@ietf.org Content-Type: multipart/alternative; boundary="00000000000068cb93059f70fed6" Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 02:02:22 -0000 --00000000000068cb93059f70fed6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all, We're internally reviewing this with the crypto team which have more experience maintaining PKIs. My opinion on an operational standpoint. I don't think I'd like having our routers suddenly reprocessing the million routes associated with 78000 ROAs leaving us with an increased surface of attack and potential reroutings. The outage lasted 8 hours as well. Even with a replayed certificate, I don't believe the impact would be as critical. And it would leave traces. If the impact of a mistake is more punitive than a proper misuse, it's bad. While I believe Job is right on the discrepancy between validators, I agree with the point of Martin on the added complexity. OctoRPKI is tolerant on absent/invalid CRLs. But it does check it against certificates when valid. Manifests are more sensitive. Even though browsers and RPKI are different, I think we can learn from the experience. Which is to get away from CRLs. https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revo= cations-compressed/ > Certificate Revocation Lists (CRLs) quickly became large, and contained > mostly irrelevant data, so web browsers didn=E2=80=99t download them; > The Online Certificate Status Protocol (OCSP) was unreliable, and so web > browsers had to assume if it didn=E2=80=99t work that the website was sti= ll valid. And lead to alternative solutions: https://www.theregister.co.uk/2020/02/20/apple_shorter_cert_lifetime/ https://letsencrypt.org/2015/11/09/why-90-days.html Looking into the data: rpki.ripe.net/repository/DEFAULT/KpSo3VVK5wEHIJnHC2QHVV3d5mk.crl is the largest with 1MB and 22027 serials. Most contain around 100-1000 serials and are a few KB. The entirety of the 17127 CRLs is 70MB. RPKI CA are already renewing, regenerating and distributing certificates often. Why not reducing the maximum validity of certificates to one day? This would relieve computing and storage as well as reducing the importance/criticality of CRLs. On Tue, 25 Feb 2020 at 15:51, Stephen Kent wrote: > Martin, > > Job Snijders wrote: > >> Of course - in making strong statements like this one I can not afford > >> to assume I am right, so if you disagree - please tell me how I am > >> wrong (in detail :-) ). > > Let me counter with a different strong statement: In the context of > > RPKI, CRLs offer no additional value and can safely be ignored. > I disagree. > > The reason is the manifests. Unlike CRLs which only say "these > > certificates are not to be considered valid anymore", manifests say > > "this is the complete set of objects currently issued by this CA". They > > also refer to concrete objects, identifying them both by URI and a hash > > over their content. This is a much more powerful mechanism than CRLs. > As a co-author of the manifest document I can assure you that these > objects are not intended as a replacement for CRLs. To provide analogous > functionality one would have to interpret the absence of a cert from a > Manifest as evidence that it was revoked, or expired. There is a lot of > experience in the broader PKI community that suggests Subjects are > sloppy about expiration dates for certs, and some evidence that CAs are > not much better :-). > > What=E2=80=99s more, they offer a soft and a hard deadline for validity= . Their > > next update field is a soft deadline, much like with CRLs. But there=E2= =80=99s > > also a hard deadline in that the certificate they=E2=80=99ve been signe= d with > > expires eventually. While the former has the same ambiguity as the next > > update field of the CRL, the latter doesn=E2=80=99t. If the manifest is > > expired, the CA is basically gone. > I don't agree with the reasoning above. It's true that the cert used to > verify (not sign) a Manifest will expire, but so will a CA cert. Why do > you think that a CA will be better at maintaining a current Manifest vs. > a current CRL? F or most RPKI CAs the trigger to generate a new Manifest > will be the need to issue a new CRL (because many CAs have elected to > issue CRLs on a daily basis). > > Further, the CRL is included in the manifest. So you can=E2=80=99t even= replay > > an old CRL without also replaying the old manifest. > The discussion (in 6486) of what an RP should do when a current Manifest > is not available, or when there are some discrepancies between what the > Manifest says and what has been retrieved allows for a lot of local > policy discretion. As a result, an RP might well accept an old CRL and > corresponding Manifest even though the Manifest appears to be stale. > > Essentially, no information conveyed by the CRL isn=E2=80=99t also conv= eyed by > > the manifest. The CRL solely serves to provide additional complexity > > for the code generating and validating RPKI objects and, apparently, > > creates ambiguity in the interpretation of the specification. > > I disagree. > > Steve > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --00000000000068cb93059f70fed6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,
We're internally reviewing this with th= e crypto team which have more experience maintaining PKIs.

My opinion on an operational standpoint.
I don't thi= nk I'd like having our routers suddenly reprocessing the million routes= associated with 78000 ROAs leaving us with an increased surface of attack = and potential reroutings. The outage lasted 8 hours as well.
= Even with a replayed certificate, I don't believe the impact would be a= s critical. And it would leave traces.
If the impact of a mistake= is more punitive than a proper misuse, it's bad.

<= div>While I believe Job is right on the discrepancy between validators, I a= gree with=C2=A0the point of Martin on the added complexity.

<= /div>
OctoRPKI is tolerant on absent/invalid CRLs. But it does check it= against certificates when valid.
Manifests are more sensitive.

Even though browsers and RPKI are different, I thin= k we can learn from the experience. Which is to get away from CRLs.
https://blog.mozilla.org/security/2020/0= 1/09/crlite-part-1-all-web-pki-revocations-compressed/
Certificate Revocation Lists (CR= Ls) quickly became large, and contained mostly irrelevant data, so web brow= sers didn=E2=80=99t download them;
The Online Certificate Status Protoco= l (OCSP) was unreliable, and so web browsers had to assume if it didn=E2=80= =99t work that the website was still valid.
And lead to al= ternative solutions:=C2=A0

Looking into the data:
Most cont= ain around 100-1000 serials and are a few KB.
The entirety of the= 17127 CRLs is 70MB.

RPKI CA are already renewing,= regenerating and distributing certificates often. Why not reducing the max= imum validity of certificates to one day?
This would relieve comp= uting and storage as well as reducing the importance/criticality of CRLs.

On Tue, 25 Feb 2020 at 15:51, Stephen Kent <stkent=3D40verizon.net@dmarc.ietf.org> wrote= :
Martin,
> Job Snijders wrote:
>> Of course - in making strong statements like this one I can not af= ford
>> to assume I am right, so if you disagree - please tell me how I am=
>> wrong (in detail :-) ).
> Let me counter with a different strong statement: In the context of > RPKI, CRLs offer no additional value and can safely be ignored.
I disagree.
> The reason is the manifests. Unlike CRLs which only say "these > certificates are not to be considered valid anymore", manifests s= ay
> "this is the complete set of objects currently issued by this CA&= quot;. They
> also refer to concrete objects, identifying them both by URI and a has= h
> over their content. This is a much more powerful mechanism than CRLs.<= br> As a co-author of the manifest document I can assure you that these
objects are not intended as a replacement for CRLs. To provide analogous functionality one would have to interpret the absence of a cert from a
Manifest as evidence that it was revoked, or expired. There is a lot of experience in the broader PKI community that suggests Subjects are
sloppy about expiration dates for certs, and some evidence that CAs are not much better :-).
> What=E2=80=99s more, they offer a soft and a hard deadline for validit= y. Their
> next update field is a soft deadline, much like with CRLs. But there= =E2=80=99s
> also a hard deadline in that the certificate they=E2=80=99ve been sign= ed with
> expires eventually. While the former has the same ambiguity as the nex= t
> update field of the CRL, the latter doesn=E2=80=99t. If the manifest i= s
> expired, the CA is basically gone.
I don't agree with the reasoning above. It's true that the cert use= d to
verify (not sign) a Manifest will expire, but so will a CA cert. Why do you think that a CA will be better at maintaining a current Manifest vs. a current CRL? F or most RPKI CAs the trigger to generate a new Manifest will be the need to issue a new CRL (because many CAs have elected to
issue CRLs on a daily basis).
> Further, the CRL is included in the manifest. So you can=E2=80=99t eve= n replay
> an old CRL without also replaying the old manifest.
The discussion (in 6486) of what an RP should do when a current Manifest is not available, or when there are some discrepancies between what=C2=A0 t= he
Manifest says and what has been retrieved allows for a lot of local
policy discretion. As a result, an RP might well accept an old CRL and
corresponding Manifest even though the Manifest appears to be stale.
> Essentially, no information conveyed by the CRL isn=E2=80=99t also con= veyed by
> the manifest. The CRL solely serves to provide additional complexity > for the code generating and validating RPKI objects and, apparently, > creates ambiguity in the interpretation of the specification.

I disagree.

Steve

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--00000000000068cb93059f70fed6-- From nobody Tue Feb 25 18:25:42 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6643A09CA for ; Tue, 25 Feb 2020 18:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=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 TSVuTkFnVOPY for ; Tue, 25 Feb 2020 18:25:39 -0800 (PST) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D23E3A0972 for ; Tue, 25 Feb 2020 18:25:39 -0800 (PST) Received: by mail-wr1-f43.google.com with SMTP id p18so1024844wre.9 for ; Tue, 25 Feb 2020 18:25:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=kS5y3qwsHU/vTQ6DeWCPbNZv+BMFlb8j2JOnfgAB1BA=; b=C5YJeGfpeSRTQKQ2FVlSESPrldi1uX7xzRcUoKHAU62JM33+nkP8o/9rZLl/EE/oLn BFCe0WNHEHSFWiyOjt7lF5rMto0XT86BJ7aGy1k2Ghk3O860RQcdHAa73N6WLp7283xV aDTUi85mm/SznsrSXc4W6DNEbTpcndc2r3ZmhGQ/nNk9rMszVV9v4iuGQCYnFdFB1xNV P+Q9GVv/ldouUgfV96pmkAxngFhnUVjlmYd3zjncxyFcgDgNQ1RRbPvq/ZazgOVqF990 cxcRK5qkiSGeK5Qx6sWmjkyYyDCT1PaDryLt6nKr/NYcB1DxIKvR55GpcPxRkakCVtaH suCA== X-Gm-Message-State: APjAAAVAY+N6M/3FZ7tL9Nqs3obGu1G5gVzl2v3dJSXRWSJkzvNgNf+0 +9z7RiTgJA05eGIHMfyHQAM4zUi8YpI= X-Google-Smtp-Source: APXvYqzyyuYlDCwqTwpIVDDEfukdUokrKu24HbwdA1opKU/pSHyHQ0cC1UN00d/U4ViLH221trB0yQ== X-Received: by 2002:a5d:4b82:: with SMTP id b2mr2310501wrt.102.1582683937271; Tue, 25 Feb 2020 18:25:37 -0800 (PST) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id u62sm858244wmu.17.2020.02.25.18.25.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Feb 2020 18:25:36 -0800 (PST) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 5deeaba0; Wed, 26 Feb 2020 02:25:35 +0000 (UTC) Date: Wed, 26 Feb 2020 02:25:35 +0000 From: Job Snijders To: Louis Poinsignon Cc: sidrops@ietf.org Message-ID: <20200226022535.GA72144@vurt.meerval.net> References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 02:25:41 -0000 Dear Louis, group, On Tue, Feb 25, 2020 at 06:02:05PM -0800, Louis Poinsignon wrote: > My opinion on an operational standpoint. > I don't think I'd like having our routers suddenly reprocessing the million > routes associated with 78000 ROAs leaving us with an increased surface of > attack and potential reroutings. It differs from BGP implementation to BGP implementation whether a milion routes in their concept of the RIBs need to be reprocessed, or only the routes covered by the (now invalid) ROAs / VRP removal. I believe there are high performant BGP/ROV implementations out there. > The outage lasted 8 hours as well. Even with a replayed certificate, > I don't believe the impact would be as critical. And it would leave > traces. If the impact of a mistake is more punitive than a proper > misuse, it's bad. > > While I believe Job is right on the discrepancy between validators, I agree > with the point of Martin on the added complexity. The only punitive effect I observe is towards the CA operators (a small group, appears not too often to make mistakes), but at the same time there are continuous benefits going to the relying parties (a large group, the internet). I see opportunity for a movement to motivate CA operators to the strictest possible interpretation of how their RPKI CA & publication process works and how the data distributed will be validated. > Even though browsers and RPKI are different, I think we can learn from > the experience. Which is to get away from CRLs. I agree this is worthwhile exploring. Kind regards, Job From nobody Tue Feb 25 19:29:08 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762BB3A0B3E for ; Tue, 25 Feb 2020 19:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lwjWeXj5Kejn for ; Tue, 25 Feb 2020 19:29:05 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4032A3A0B3C for ; Tue, 25 Feb 2020 19:29:05 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id i23so1281593qtr.5 for ; Tue, 25 Feb 2020 19:29:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=53fakRq5Wz1pKNCLiKlQPN7lI4zUxrYOA/QuJ9+KvCo=; b=Kwj3odIvR8gfYwpHDrW0d68LqTyc7b+gMa9/stpWXvgjt2NlBcMJFT7kkRRb9EcuW5 dToqVc1biPTai41daL7FDRumnGsk/3DcLc976IMty97qP9lsiMRiy2OaxbqtUDFhUW0L 2bHtvmNNRiIbCh3HUqDixIzcz8Rd1rR42/5Tki1wSRP5jqrgz5AcohfLaaYvMwwHVytt h0iTyRZd0WtgkQqsl/JeihtL7ln87suV1e5Sq+Ykk6OpSjJJCvGIh/kprCNpdB6CUOpc G1EeUu16fMkfR2sOmzQOqNv7tHq56bfhvjSsVwwF+35Rt2IfnV+OgDFgpbO7vl63k2tq xr5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=53fakRq5Wz1pKNCLiKlQPN7lI4zUxrYOA/QuJ9+KvCo=; b=oB8/KnxuD/yQJP+1DPoWHVJ1nL0GrzYAbeAI+sLQG4L3q/yVasU0N8bygfrdE8euHm 0UKOMI4aJhmroBTUNQFpc7ravaeqpjdbWYbYUBRViggpAzBoKZXizZ1YqT/v/o2aFdKy xg07CIBqLNFsMV9aqYIWXOU4bNg/88Fu3pg3ZHh7bGp59eaH0YsLNEQieZemb8urCkml 1OowB7mOflv+MuZddk9KoxahvFp4Gtr9WUTxfkOMG9DoriQ0r/YHRDmSci20Hqtq6LKT sPwfEHu3OXbIx7a5gIPVj9CTwlTRkibSUaVnAYjA61G+ARTt9mlYN2Vn6Kxxpm8UFUPY GgHw== X-Gm-Message-State: APjAAAXigS7TSQoxNGdwjrv1uq4mbNFLI8wFaiWbvf2pORrAdSpcGuRV 9XgMaJnw53dsmtP4z5IR8XZbRarUP0MJA9xX2mk= X-Google-Smtp-Source: APXvYqxGfkzujGGplXme+3eJpo8SknOXKn/2vMy2FC61rYIICEks9F20R1YJfOZai2QpKjcDiiObqKBnQY27m1e9cc4= X-Received: by 2002:ac8:5457:: with SMTP id d23mr2437881qtq.93.1582687744059; Tue, 25 Feb 2020 19:29:04 -0800 (PST) MIME-Version: 1.0 References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> In-Reply-To: From: Christopher Morrow Date: Tue, 25 Feb 2020 22:28:53 -0500 Message-ID: To: George Michaelson Cc: Stephen Kent , SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 03:29:07 -0000 On Tue, Feb 25, 2020 at 7:24 PM George Michaelson wrote: > If you cannot see a CRL which you are told should exist, to assume the This wasn't missing CRL, but an invalid one, right? Does that change your mind on how you'd manage this sort of problem from the (network) operations side of things? > CRL doesn't matter feels extremely unwise. I may have mistakenly > published entirely cryptographically valid things which do not now > inform my intent, and I have tried to repudiate, and you cannot see > that repudiation and now interpret states of routing in ways which do > not reflect my true intent. So, to bypass the CRL (in all cases) seems bad, sure. To bypass it (or enable a bypass) in cases like this (clearly some mistake let us get to this discussion) in order to keep routing packets 'properly' (ha!) doesn't seem like a total disgrace. If the CRL mistake is a the RIR publication point/top-of-tree it certainly seems a bunch more important to fix the problem 'quickly', however, I'm not sure 'quickly' is much more than the experienced 8hrs this time given some default numbers in validator code bases, right? From nobody Tue Feb 25 21:29:54 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8C33A0975 for ; Tue, 25 Feb 2020 21:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=algebras-org.20150623.gappssmtp.com 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 mpq3UdhrEsoF for ; Tue, 25 Feb 2020 21:29:50 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A617C3A0976 for ; Tue, 25 Feb 2020 21:29:49 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id l4so1333556ilj.1 for ; Tue, 25 Feb 2020 21:29:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1HqC8XGRbF85s+stuam52IvH+K66oPII20Re9ez+q6s=; b=FnQ7/2BiwdL/lMfkFIpBsBju1XDNUH2wfKpmyAyPP5z1ZI+7cphcgXzjIXpctAjABf ygGWXlcEOILd/a6ZrPjQfNPcCAxvERzcXe2qtkrImhUhoJPibbznBDfXs+KBN/lAcNqY bt7hb/e9NGU3JnQizuAY2BU4GMsr+PHeA43f1yOsvugZsZwdUwnH/CSX+aU8c2ka2GYA ow2AZsDGujCYBXfMRx7mVxtQMkrndwwlmsuwI/FzzU49QAxlTbzJeZnJ+tX8dFDuetfK iVy4OURO4PO4D6rFW4SC2Iuh+sSUJZEwErTuA4jOvNMMhzIz5e9KMKi+aTMoegFt1fKT oMzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1HqC8XGRbF85s+stuam52IvH+K66oPII20Re9ez+q6s=; b=sGyqoMyGu3bJdZZf2mq0pjngeLe6hT9LAlwJREwscKGSBHVTLr8KQInGIlePiYICb4 w9aynzjee5WmSEB8FBWiGNUXx3tZaxq5Fdn6trP9+1WUIswaMYGHuJbbwrBL7nrRf5up g3sIZJMnF5+aFD4xRCSPExo128cwWdXEfOn5NHYyL2rVuR/IIktvOK6tNhto1CCcd4Q4 8RtvAbhip8y24Q3gC+IF30mMtP1XdIpVhKp0I3o1gQV8KmUEHlDk+h95RK1tX63iBgsS SQYpajBriMdTpwWIwivXPYozhxsw+FqwX2d4y+iJROaxIoKwqhXnx3bH/O5xbxMT0OTj wl5Q== X-Gm-Message-State: APjAAAXInTW6mWIx/tgiiaR3Z7pB0tPpZZJnh86IEPM10Vp55C08f1kz gE8Wi0ylZgHHIAwoxCz6/dz3jN1tl8vd2/lZHHooeg== X-Google-Smtp-Source: APXvYqxiszROENVJMUCFzJ8xQzfT3G9jrbap7Zeue1qDX6Jm1o3ybssWSR0e6ZH98NU7PqRdKTUPsV8ld46rnF5HI/8= X-Received: by 2002:a92:3cd7:: with SMTP id j84mr2699016ilf.176.1582694988327; Tue, 25 Feb 2020 21:29:48 -0800 (PST) MIME-Version: 1.0 References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> In-Reply-To: From: George Michaelson Date: Wed, 26 Feb 2020 15:29:36 +1000 Message-ID: To: Christopher Morrow Cc: Stephen Kent , SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 05:29:53 -0000 the questions you pose come back down to two things to me 1) high-in-the-tree burdens exist. They're not more complex than low-in-the-tree but they (by definition) affect more things, and more people (RPs) -I have suffered failures in my service as Nathalie has, and I respect her integrity in doing a public disclosure and root-cause analysis, and I feel a similar burden. You need me to be able to say "this happened" and I have to accept you saying "what have you done, to prevent it happening again" just like Nathalie did (and accepts I believe) 2) "how do you know what it means" is really hard. A lot of statements about "..and so this means" are post-hoc interpretations of what the CA and RP *think* the situation means, but the intent is actually not overt in the situation, its latent. If you cannot point to a document which clearly says what a situation means, then I feel its undefined. That is what spec work is for. Thats why we're here. The CA did not mean to fail to publish a CRL. The RP is faced with having only out of date CRL. "what does it mean" is really hard to infer a priori. Is there a documented intent of what it should mean? Do we all agree? I feel the CRL situation is like that. There should have been one. There are only stale ones, or a badly informed one. It is confusing. Incoherent. It feels like we didn't say very clearly "what does it mean" in the spec process, if people feel there are open questions and are free as RP to interpret this, I feel we didn't adequately wire this down. If thats not true we shouldn't be discussing it, because it is documented. if you like, the question for me is 'how did you get to the word "clearly" here, because it feels like "clearly some mistake let us get to this discussion" is not a-priori, but is post-hoc reasoning, because Nathalie told us it was a mistake'. How do you know, in advance, the bad CRL situation "clearly" is a mistake? You have to ask "did you make one" and if the CA says yes, then it is possibly an RP problem, or an attack along the path to the data, or some other issue. If the CA say "oh no.. that shouldnt have happened" you "clearly" know its a mistake, but that depends on asking, and being told. Remember we now have RSYNC and RRDP, and they do not actually have to cohere, they are obviously by intent meant to be eventually consistent, but we have two ways to say what is the state of a repository. This means there are at least two ways RPs may synchronise on the state of a repository. Persisting state measured in hours around states of a repository do tend to align in both worlds, but I believe its possible for the persisting state to be incoherent (I believe this, because I believe it happened in the APNIC repositories) which is an added complexity. I think I would like a world which said "if the thing I see is malformed, and if I can tell its malformed but I can also tell it was well signed, I will go with operation error, and consider fallbacks" -but if the thing is missing, or badly signed, it feels more like an attack, or risk of attack. Well signed, but badly formed is the special state of "you did this, but it is wrong" and so I do break it out. I could believe we want some fallback behaviour. I could also believe "wrong is wrong" is a better place to be. -G From nobody Tue Feb 25 21:53:39 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133AC3A0DF9 for ; Tue, 25 Feb 2020 21:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 pF7tlWvZlBRL for ; Tue, 25 Feb 2020 21:53:37 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6E73A0A59 for ; Tue, 25 Feb 2020 21:53:37 -0800 (PST) Received: from [10.0.0.155] (c-68-32-79-179.hsd1.mi.comcast.net [68.32.79.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 67E8654016E; Wed, 26 Feb 2020 00:53:35 -0500 (EST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Jared Mauch In-Reply-To: Date: Wed, 26 Feb 2020 00:53:34 -0500 Cc: sidrops@ietf.org Message-Id: References: To: Louis Poinsignon X-Mailer: iPhone Mail (17D50) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 05:53:38 -0000 I get the intent here but 24h is too short. If there is a hardware failure o= n a holiday weekend or natural disaster it may take too long to recover ones= systems.=20 In the event of some global pandemic I could even envision it taking longer f= or small operators.=20 Sent from my iCar > On Feb 25, 2020, at 9:02 PM, Louis Poinsignon = wrote: >=20 > Why not reducing the maximum validity of certificates to one day? From nobody Tue Feb 25 22:12:40 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98BD3A0E4F for ; Tue, 25 Feb 2020 22:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9BN5KBtxh0zQ for ; Tue, 25 Feb 2020 22:12:37 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 A8EB33A0E4C for ; Tue, 25 Feb 2020 22:12:37 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1j6pvw-0007ca-Fb; Wed, 26 Feb 2020 06:12:36 +0000 Date: Tue, 25 Feb 2020 22:12:36 -0800 Message-ID: From: Randy Bush To: Louis Poinsignon Cc: sidrops@ietf.org In-Reply-To: References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 06:12:39 -0000 > Why not reducing the maximum validity of certificates to one day? for example, because the CPS of at least one high level CA is, or at least used to be, only willing to commit to publishing once a day. as i said elsewhere, this is much ado about a non-damaging ops gl!tch. exposing our weak PKI clue and inclination to more complexity is not constructive. randy From nobody Tue Feb 25 22:27:55 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786283A0EA9 for ; Tue, 25 Feb 2020 22:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com 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 FSD-d6cOmYDx for ; Tue, 25 Feb 2020 22:27:51 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970ED3A0EA7 for ; Tue, 25 Feb 2020 22:27:51 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id s24so2106010iog.5 for ; Tue, 25 Feb 2020 22:27:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=vndgSmZxrkE6TG2RVAHiYY1gnbnBksgT/zEXOy9+Tys=; b=exVb99HUPUBFSS6hja5JdXrLHD41SsYn0S0tRDdlzxHc+qECNXjeaSoZDKmyXGuOX/ O4l1reUPri42dahj9Fh/HUHSO+v43LNjcRjSxKU6Bfbk/WFbCVJYVWyatfvi4dgAzpXd yp2OzaTbVwrYSJskIUPnYoHH0MtfOweJXdpLTN3Ciz42WTyvxii3dViA684+l8UPpl7l ZnY+Yz5ncKd+vGFmQgEA4O0LHAJdo7sWdsoJDQFPu10ILCWKvenz5vzJmDmRuAeiGORu gSz/kltktcTv3P2WSpa7gIdJZNaGQqu2woQOHshf1SI4508AHJt89p60VHKwTIqmQfZn zPFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vndgSmZxrkE6TG2RVAHiYY1gnbnBksgT/zEXOy9+Tys=; b=YRh2gIsVqTpokiGogQteYP7I8Wms0QzFir7B+sYHxpcVe5OCoal60Pv37eyj57vP0O spQ33XjVIYM3A2IRCP3Mf9lqAYdRl9lazabbfWMS6zoBNvzvA9SaHBA55BijsoUOg+fE VrWljPigawhRftH1IGGb8pj5iKFdXGXsgTVV7UUCuwpWEVOdUOpDbDcXVZKlYVt9EbVB RXEi3H6AWj1smvHFcygbkDHljFwl3N00VhHOalnUtuPVYrzOy7BeFZvoeTgrvjgvSu3k KakwFSocEPrXdYeY3MC4BT39n8ntlhV+xDZBfapSqpNC3un7vO46sFZ4HGSFsHvQNuaW CoeQ== X-Gm-Message-State: APjAAAVH1u6DubbYqz12da+s7z/bCo8+65gpfg0sQ3v4On2n7GwVY0T/ afKF6K55eDCfrKVzmIPB1MwG12GwSi09dq6cNocJA9ohwWDNAg== X-Google-Smtp-Source: APXvYqyKonaUPC9CEcN1LXGemw+fGDnzoY1sef/WJyPIsksZbfn2i0EHYVOaNSwwn4zLMryYfV4aDKUNtlz4NKRr0uM= X-Received: by 2002:a02:cba5:: with SMTP id v5mr2375230jap.64.1582698470543; Tue, 25 Feb 2020 22:27:50 -0800 (PST) MIME-Version: 1.0 From: George Michaelson Date: Wed, 26 Feb 2020 16:27:39 +1000 Message-ID: To: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Sidrops] AS0 testbed at APNIC X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 06:27:54 -0000 If people would like to look at an AS0 state, APNIC's AS0 testbed TAL: https://registry-testbed.apnic.net/as0-test-ta.tal APNIC's AS0 testbed SLURM file: https://registry-testbed.apnic.net/as0-test-slurm.json ~3500 objects, we do not publish one ROA per prefix to avoid a large object set, we do not publish one ROA for all AS0 to avoid a single large object parsing burden. ~65000 prefixes, because of sparse V6 allocation outcomes fragmenting the allocation spaces. From nobody Tue Feb 25 23:53:25 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B253A0FFA for ; Tue, 25 Feb 2020 23:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 oTCoVoyrJ0Sk for ; Tue, 25 Feb 2020 23:53:17 -0800 (PST) Received: from smtpproxy21.qq.com (smtpbg702.qq.com [203.205.195.102]) (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 3232E3A0FFB for ; Tue, 25 Feb 2020 23:53:14 -0800 (PST) X-QQ-mid: bizesmtp19t1582703588torqvr88 Received: from [192.168.3.24] (unknown [118.198.173.48]) by esmtp10.qq.com (ESMTP) with id ; Wed, 26 Feb 2020 15:53:06 +0800 (CST) X-QQ-SSF: 00400000000000N0ZI80000A0000000 X-QQ-FEAT: 96xsOYpMbcrHEUX3H6/W/gY9hp1ZQ/3m04QnskroFJkTJgsvv8qowwF7ebePX 6112ekVIjSIprm9vnqpQfVwtHC8Uj4nW/RraaooTim1vipq1ANM/TZfEkg+2FsnAfTvih8u SS2m6pjQ/33x25Ez95CbXAhswQc8BIPPKYekH9SsE+yHxRM2XlofetcuhRxYjstayx0acSq iwlwf/zXtP/TLYp36VvSubmdxKundgy+MEtUVlVsXSOy43UuPTvYAHrn6xKP66VI0eHNmLe x/rA8+LXyq3ZoMGKMj0kLheCFdZ3w+k0Aha79rD5PnNDymdmDLrcoyvKsTF56fn/pqEdS+l L4fQ3cQi2WSPMbITRXL4lZv4eiI0w== X-QQ-GoodBg: 2 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Di Ma In-Reply-To: Date: Wed, 26 Feb 2020 15:52:53 +0800 Cc: Stephen Kent , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <3D64213F-4318-4869-A5DB-0503F7A17AA7@zdns.cn> References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> To: George Michaelson X-Mailer: Apple Mail (2.3608.60.0.2.5) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign5 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 07:53:23 -0000 I think CRL is indispensable for the RPKI. I am reassured of this argument especially by the point that George = makes here.=20 As far as I observed, CRL is issued in case of some hazard things = happening such as key exposures, which we weigh much worse than = expiration of CRL. As the administrator of RP software RPSTIR, our implementation sees = certs invalid even if this CRL is expired. We assume that the INRs = covered by those invalid certs should be put into newly issue ones if = the very INR holder would like to activate them in terms of routing.=20 Di > 2020=E5=B9=B42=E6=9C=8826=E6=97=A5 08:23=EF=BC=8CGeorge Michaelson = =E5=86=99=E9=81=93=EF=BC=9A >=20 >=20 > If you cannot see a CRL which you are told should exist, to assume the > CRL doesn't matter feels extremely unwise. I may have mistakenly > published entirely cryptographically valid things which do not now > inform my intent, and I have tried to repudiate, and you cannot see > that repudiation and now interpret states of routing in ways which do > not reflect my true intent. >=20 > -George >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops >=20 From nobody Wed Feb 26 00:28:41 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFAF3A1086 for ; Wed, 26 Feb 2020 00:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9kG04qzCMw0j for ; Wed, 26 Feb 2020 00:28:38 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 395B83A1085 for ; Wed, 26 Feb 2020 00:28:38 -0800 (PST) Received: from allealle.ripe.net ([193.0.23.12]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1j6s3X-000AkQ-IS for sidrops@ietf.org; Wed, 26 Feb 2020 09:28:35 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::279]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1j6s3W-0002GZ-E0; Wed, 26 Feb 2020 09:28:34 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Oleg Muravskiy In-Reply-To: Date: Wed, 26 Feb 2020 09:28:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <766BF90A-C42B-47B3-B62E-C429E48BBBD7@ripe.net> References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> To: SIDR Operations WG X-Mailer: Apple Mail (2.3608.60.0.2.5) X-ACL-Warn: Delaying message X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b74f827bbda451a15ec68e00dc1054d1474 Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 08:28:39 -0000 I tend to agree with Steve and George that manifests could not replace = CRLs. And while the rfc5280/section-6.3 only demands to fetch the = (time-wise) valid CRL and does not specify what to do if that isn=E2=80=99= t possible, my interpretation of this section is that the validator = should not accept/ignore a CRL past its validity period. With regard to manifests, the number of inconsistencies between the = content of a manifest and a repository, the absence of rules of how to = handle these inconsistencies, and as a result, the complexity of = processing manifests during validation is much higher than the = complexity of processing the CRL. I would rather get rid of manifests = after fully transitioning to RRDP than putting more responsibilities on = manifests. But this is of course me as a software developer speaking. The decision = should be made by operators. Oleg= From nobody Wed Feb 26 01:25:29 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBF83A115E for ; Wed, 26 Feb 2020 01:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 agQPSqWWp-ws for ; Wed, 26 Feb 2020 01:25:24 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 1F6523A115B for ; Wed, 26 Feb 2020 01:25:24 -0800 (PST) Received: from [IPv6:2001:981:4b52:1:e904:10f0:2e43:6a13] (unknown [IPv6:2001:981:4b52:1:e904:10f0:2e43:6a13]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 8F4C72B9E0; Wed, 26 Feb 2020 10:25:21 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1582709121; bh=k71F5j0xllqZD1VwoQDLw3Mozxph69L6aG0qs/W/Nes=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=a/mhNaVIbE2ZyyW0QV3+Q2hNhRJXAJ1jmV1D7xYnpDrbsLEjHcNZRZYF+mG6bcuZU ABwvkrJAI1zUtTcIoNnctzANLapMr/Cu7gUCiFZlwkuU6vRC0C3GqYj8BQP8AbcHSj 9Z1AnB7jmuBK5GBytARfuZK08ZsChfsAcK2oj2vE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> Date: Wed, 26 Feb 2020 10:25:21 +0100 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> To: Stephen Kent X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 09:25:28 -0000 Hi, > On 25 Feb 2020, at 17:55, Stephen Kent = wrote: >=20 >> Further, the CRL is included in the manifest. So you can=E2=80=99t = even replay >> an old CRL without also replaying the old manifest. > The discussion (in 6486) of what an RP should do when a current = Manifest is not available, or when there are some discrepancies between = what the Manifest says and what has been retrieved allows for a lot of = local policy discretion. As a result, an RP might well accept an old CRL = and corresponding Manifest even though the Manifest appears to be stale. To me this is the core of the issue. I have searched through RFC 5280, and RFC 6487, but I cannot find clear = guidance on what to do when there is no valid CRL available at all, or = if the only available CRL is stale. RFC 5280 seems to say that one = should use the best and latest valid non-stale CRL information to make a = list and consider certificates revoked only if they appear on that list. = But the language is hard to parse to me.=20 We have had discussion about this in past meetings, and my = interpretation of the outcome was that stale CRLs should be handled in = the spirit of stale Manifest. But there is no written guidance, so it = remains pretty vague and as a result I can see any of the following = becoming local policy: - disregard invalid CRL and consider nothing as revoked - disregard stale CRL and consider nothing as revoked - disregard invalid CRL and consider everything revoked (because it is = now unverifiable whether they are) - disregard stale CRL and consider everything revoked (because it is now = unverifiable whether they are) - use stale CRL as normal I have always had issues with the amount of local policy in the manifest = RFC (6486). Inevitably this leads to differences between RP = implementations and possibly even between installations if software = provides configuration options to users. Again, and again, I find that operators expect that the validation = outcome is the same everywhere. This is not the case. I am not talking = about local exceptions, routing policy, or temporary differences. They = expect the same rules to apply. And I agree. We would be in a better place if we did have one clearly = defined way to deal with all this. One possible interpretation of the Manifest RFC, one that is used by = most RPs, is the following: - Reject the manifest if it is invalid: its EE cert expired, wrong = signature etc. - Warn if the manifest is valid, but it is stale (here implementations = differ, some reject) - Only consider objects listed on a valid manifest - Reject any object for which the hash does not match the manifest I understand that as written today there is no consensus on this. But if = we could, finally, agree on a way here then I believe that that would = simplify everything greatly - without impacting security. RFC 6481 (Repository Structure) says that all currently valid objects = must be published, and that invalid objects must not be published. So = using the manifests as a signed statement of what is current and what = must be regarded seems like a very plausible approach to me. The = manifest EE is signed by the same key as the CRL - so unless you want = enforce security through pedantry - there is no point in checking the = CRL for objects that a valid manifest says are current. There would be a use case for CRLs for anything published outside of the = RPKI infrastructure - so I still see a theoretical use case there. I = think that it should be applicable to yet to be defined object types, = defined by OIDs and all, that are not intended for publication inside = the normal RPKI structure. The CRLs would be much smaller, and would not = need to be updated whenever a new manifest is published. With regards to stale vs expired manifests: we discussed this many = meetings ago. I like the idea of having things go stale, resulting in = warnings that can alert people to fix things, before expiration. This = could mean: next update in X hours - after which RPs would see a warning = that replay attacks could be a problem, expiration in X days giving = CA/repo operators time to fix things, X days being a hard limit on the = replay window. But, more importantly, I think we should aim to agree on = a common way to deal with this for all RPs. Tim From nobody Wed Feb 26 01:27:41 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F643A1166 for ; Wed, 26 Feb 2020 01:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 dKpTCPFPhP3g for ; Wed, 26 Feb 2020 01:27:39 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 DB2D73A1165 for ; Wed, 26 Feb 2020 01:27:38 -0800 (PST) Received: from [193.0.23.13] (helo=bufobufo.ripe.net) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1j6syf-0004Pz-JQ for sidrops@ietf.org; Wed, 26 Feb 2020 10:27:37 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::3f0]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from ) id 1j6syf-0007tj-Gq for sidrops@ietf.org; Wed, 26 Feb 2020 10:27:37 +0100 References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> To: SIDR Operations WG From: Robert Kisteleki Autocrypt: addr=robert@ripe.net; prefer-encrypt=mutual; keydata= xsBNBEzFa6gBCADVASYXBbUF7v1D+Y9XR41SEEMiZUARlUWeP0NrFHZmRRGdR5nM/p6HguUd StIPRmdqMdyLDqBsV8XPVu6lvhcb4+ZFu/V1XFPVyPBH8U6iQ4PdGDeqFlBm3gxoDOGraGw8 bjojvASTz/Wk3ddLPm34Kb6oMI2MclC016UgrPgIj6A1Uu8qQeBDyWrk+OrWUPOUOKM7QhQg cpU4JwuaesthFvqdoPNQJi9QUfn94r14ZNDYmeJlchZiRHWO70Gwoy3ywfAM9Kyi1tx78Qc9 E5ZhGIw9qqlzqa6c6a0qhup2Zh/dhVBJ05jCDN7bUQT5tRiOV2icyX8Dsr4KaWYCsAOVABEB AAHNMVJvYmVydCBLaXN0ZWxla2kgKFJJUEUgTkNDIGtleSkgPHJvYmVydEByaXBlLm5ldD7C wHgEEwECACICGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJWUwoeAAoJEC0ZXiKtTC3+ 04UH/jlvSR0esDGFSponUVawru+/QF61KdsNrdH6/Vs2buQvczW2Uh+S6Dic2vr2H0B1YrvL F2XpL2WJUHBUDLTA7dYTslvnHpyZrR8Sfb+h+wJ8OynxEC5wMKxfYNx2fMSk5EIU5mRjMaYg X/VkssDcoQAznNwVVYeqHYUJDMcrJhAYh44VHO208VwjPjHUDRlC+BoMGjHJnWDOAstlES8j 0r3adj2MqIHdDEjSdEx1+rbV0iZlgcDbYDex3qulOYlcZL+PJvGHzD6CkNBa8SbSN7cO0yqR OJ2sgobITOJ0GbRIbIvkUe1Iqw717CuQV/u822dFISDYOAhGYmfWGJWmkezOwE0ETMVrqAEI AKazZ2Agrv0nNFPWV69l6fEout/FaqWfyAG5V414l4yr+qVShUYzS+txA2vC+ouHvdORZ/JG xwKf6HE+YvvWS+Oa+b6h+GZfA3G43XGpQlxXrFK019TeMjhHqWprZALL4w2k6TatYT1ZW369 rORtwSgtn5ZC4uNcpZeDQddQvCjyYoknqlZqAFf1pssuGPTE8GvhrZGEp52dALYYoDIf7y/z 8fCAcy72rhMhQV02rPB49UxOEh2FZJhST0743tuMtFemBkp06B/Mcx54QT0muG8zj19oMDG3 AAaGjNP6B3qzR6F8VczR/qVhQzRvNMr8A6+y/ew/x4+48P+O/4n/I50AEQEAAcLAXwQYAQIA CQIbDAUCVlMKHgAKCRAtGV4irUwt/mvlB/sFID7mlsWAS66UyrI+tGs4Xfl59vvhRRZ4ZKiR 8VEbWbLKh/b9SoYcKt9SLEfVxJE5ebWPgIIvUSdLS6f4n9uAJteDZ4w/AVfp5a6jbfvMm7JP AMW4HtnZ3YbNevRgXdGVXN+bTLZzXoVijOKu+xHDBRNaUswaG3glrDJfUGkPQtCXFn6m6Pdw dW1/ShzwQgfuE/NXa83jhJ175P+NoQ2KG7934vu2MZdrtIqPibKuaGWMPG0L5YzPotK9ONmd taJMnuk92qqZ6S9JPwRZmogRW/sX54XvGg6RzNpdHS5C+iN01tCNJTRTlOJ1X73+RrGokvKc dp6fdfc4PHHhpcMd Organization: RIPE NCC Message-ID: <8b5665c5-3093-571d-bc53-41410eb4a44a@ripe.net> Date: Wed, 26 Feb 2020 10:27:37 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ACL-Warn: Delaying message X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274171b8ce1dd0f5d2d550c8a72ce797288 Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 09:27:40 -0000 > How do you know, in advance, the bad CRL situation "clearly" is a > mistake? You have to ask "did you make one" and if the CA says yes, > then it is possibly an RP problem, or an attack along the path to the > data, or some other issue. If the CA say "oh no.. that shouldnt have > happened" you "clearly" know its a mistake, but that depends on > asking, and being told. And in the meantime the RP software has to make a decision one way or another, and ultimately to send packets either left or right. It can't ask the operator to reach out to the CA and wait for the answer, because the decision depens on what they say. So ideally there's an ultimate guideline on what to do with stale / invalid CRLs/manifests or perhaps there should be configuration options to RP software the operators can tweak with (highly) recommended default values. Robert From nobody Wed Feb 26 09:03:41 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05233A0C3E for ; Wed, 26 Feb 2020 09:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=verizon.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 SV5pb3ocbRSP for ; Wed, 26 Feb 2020 09:03:38 -0800 (PST) Received: from sonic303-2.consmr.mail.bf2.yahoo.com (sonic303-2.consmr.mail.bf2.yahoo.com [74.6.131.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4153A0C07 for ; Wed, 26 Feb 2020 09:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1582736617; bh=7WlOx5qqP3m3cVLQdxKHmGp5HlYQEc1ZmIfil16/itc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=V6sFMvWJBL+LyqzBVgQBR6rlx7LGrh7wMD1XFsdxv6jPKZaxqiUaqJeIro+4/zq2glJv92T3fAhH/7roBGZTF1FCeKOpkRSwAEXB7B6fnp4q0mTNZWq9yyBIpUn8HISzM6/w7KnxQNvzp/F1mCLomt0qy30no2G/sQphWrqU2E2Ui5dabHxMVEtVvYyQroHL3bEAu1l0+6+cKBsrVnUdC+DoLAI9BpXrBBgj/bcMrKJx70pi7p+2dMKtH0Q4NowsWADn4mOra7vVLisUg5E84Ang5mqiQEP/3WDmBD8Ad/4Lrz/NoysB1pEIUdtcBYHZjZpJZ4FdDT31nE0Rvy1o1A== X-YMail-OSG: bxUjFAUVM1k7EzHHbwB84cz95p99tXY3eOU394cyehonWmqRq3cCWeTtEFMPVHF WVuilvJLwdJyFlv2zaZ4N7yWv31AYLny0h.nQeafrjA57BUVHpC7J6np90NkLas3UpUB8_rvfKpI lXa3s3HGWBTNrJJjJ2SI6TxMTP8YjnvxqCbxp2UGdAGyNa1HmcnsBh9o.QkqBYHnImqSy2nmbzW3 1RkBysonUoHj8RD9e8ktB0vLVFTtpzkYv3egJ5HRXrf2iDPGYDugMxxRxiAQVO3oWG.WMoSyLLba qPqtUbBd_fKr.uH5C7DIqY.3CgdC1wefSJcLA5xHn191iiJCKPaf6.W._J4S80WDfHhCneSZN1q0 eUvwwPssVJkydfuBq2R_g2KdMsnN.EW0nHzbFRDjRRA79xwd8Ge3pHLn2QkJFUna7wjndG1VHb_. tLcaWq7GxzjPTtG61WwS7otm41ujJKuiz28OtY37vhFYATPkzDIdRXDl7vR484V6bK1OXE9WZ2uQ 0Cnl92vp1NI49VAJiWVPuCz.01LzLnClVPdfIVYRw1FBAixGc57uZy8zK6wCxN5FWZcJM5vhYzAB fI41o7heGRsKE4q6AEMujKimF61B5tm2z780knFAPKGhBQl8Jmf4LETzbGzxp5CB8Ga6GJSjHE5L FD9kbGQyeSIikMxs9_iWa_0ZfJfFCnbxQKLGhbox.7UQUCrAhhrHDHjKbqfYFSkVFpMH1j9BhJ6. 0g9qIDB5ZIO2lWaUZP2TYbZp3C3sT.hzuLV745uQqLE1PMmtUT6hoIvTi7zxCl4ISpKBqcEMQDT6 s_O7_1LxUxkNmLJzjl0tWOgkOZtZDApa7pY2wTae6tKlUS.xXKkLysL3xNas9pOb1Ixs_i.gEMzC u1IahtAvTdrqjU2GB0jsGE6G6z80iuidb0_ywlpl5lQee9iJr55njY0kZfC1uaPor50_vceo1FrB PznPGTiW30YRMWe_zx.5bVdH.g61r53E9qZ45ZUZMVDbNVnrsjU8xpXHh691oKI15wlKngqmsP1J S6386t8IhowgdGARZpdZOqlaRQhNBfitc6VaapXURgOdjOUfcSKRWcf8mJHg.HICiqPZO9UKXsZF hrcvwHTkAid8ltStoA7KzSeG1imhxxna2T3xg6GaMO1ggiOjdViSmClr1Wudcgv9Y89fO1_ne87E 1F7.mp16T4lipYrkcoNn4hgJ.b4H8bqU1Ca8Teg9j7NSNkto15bYumWUKpnwmzNUwjbn4KQSgZkB wwRxyYrYlnJ3GDsZ9zx2lPtwuKotmh2m7IfSg3CwX.sJlw63pfO17gYvJIX0TNGaMDHXcRO5Lpbu WuH0XAsRbdBsHddV.0X6eGrrwEDxoL0WXnYVXw3Qu9R0VYCm7f2TPMjZch6aZKHzNtUxFVVU7s_r uqD61rzh36iqnkzaW7ucfxOf7yVo.Kc1jOKXT Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Wed, 26 Feb 2020 17:03:37 +0000 Received: by smtp418.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 83f24b3b8b0e9039caa8051553f64758; Wed, 26 Feb 2020 17:03:33 +0000 (UTC) To: Tim Bruijnzeels Cc: sidrops@ietf.org References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> From: Stephen Kent Message-ID: <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> Date: Wed, 26 Feb 2020 12:03:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.15302 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 17:03:40 -0000 Tim, Thanks for your thoughtful analysis of the options. Her are some additional thoughts. In general, a stale CRL still represents the best info re revoked certs available to an RP, so ignoring it does not seem appropriate, to me. In the RPKI we also have Manifests, so if a Manifest is current but the CRL it references is stale, then that strongly suggests that the CA has encountered a problem generating a new CRL, but it's still the best revocation status info available, so use it and consider contacting the CA (via the GB record) to point out this problem. A CRL is invalid if it's signature doesn't verify, or if it has a syntax error, even in the face of a valid sig. In this case I would ignore the CRL contents, contact the CA, and keep using the freshest CRL the RP has. Because these CRLs MUST contain sequence numbers, receipt of a valid CRL that appears to be current, but has an older (or the same) serial number relative to a previously validated CRL is suspicious. I would definitively contact the CA to see if it just forgot to increment this field properly. I probably would stick with the freshest CRL info I had for that CA until the matter is resolved. There are more cases one can analyze, but I think the basic approach is to stick with prior, validated CRLs and contact the CA that issued the questionable CRL, until the matter can be resolved. As for the considerable leeway accorded to RPs in the Manifest document, I concur that it allows inconsistent local behavior. If the WG can agree on more proscriptive language, that would be good. When we wrote 6486 we were unable to agree on such, as we tried to balance robustness vs. responses to possible active attacks on repositories or communications between an RP and a repository. Steve From nobody Wed Feb 26 09:03:45 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3430C3A0C07 for ; Wed, 26 Feb 2020 09:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.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 G5S1FwNe2uPV for ; Wed, 26 Feb 2020 09:03:38 -0800 (PST) Received: from sonic303-2.consmr.mail.bf2.yahoo.com (sonic303-2.consmr.mail.bf2.yahoo.com [74.6.131.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4843A0C3A for ; Wed, 26 Feb 2020 09:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1582736617; bh=7WlOx5qqP3m3cVLQdxKHmGp5HlYQEc1ZmIfil16/itc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=V6sFMvWJBL+LyqzBVgQBR6rlx7LGrh7wMD1XFsdxv6jPKZaxqiUaqJeIro+4/zq2glJv92T3fAhH/7roBGZTF1FCeKOpkRSwAEXB7B6fnp4q0mTNZWq9yyBIpUn8HISzM6/w7KnxQNvzp/F1mCLomt0qy30no2G/sQphWrqU2E2Ui5dabHxMVEtVvYyQroHL3bEAu1l0+6+cKBsrVnUdC+DoLAI9BpXrBBgj/bcMrKJx70pi7p+2dMKtH0Q4NowsWADn4mOra7vVLisUg5E84Ang5mqiQEP/3WDmBD8Ad/4Lrz/NoysB1pEIUdtcBYHZjZpJZ4FdDT31nE0Rvy1o1A== X-YMail-OSG: bxUjFAUVM1k7EzHHbwB84cz95p99tXY3eOU394cyehonWmqRq3cCWeTtEFMPVHF WVuilvJLwdJyFlv2zaZ4N7yWv31AYLny0h.nQeafrjA57BUVHpC7J6np90NkLas3UpUB8_rvfKpI lXa3s3HGWBTNrJJjJ2SI6TxMTP8YjnvxqCbxp2UGdAGyNa1HmcnsBh9o.QkqBYHnImqSy2nmbzW3 1RkBysonUoHj8RD9e8ktB0vLVFTtpzkYv3egJ5HRXrf2iDPGYDugMxxRxiAQVO3oWG.WMoSyLLba qPqtUbBd_fKr.uH5C7DIqY.3CgdC1wefSJcLA5xHn191iiJCKPaf6.W._J4S80WDfHhCneSZN1q0 eUvwwPssVJkydfuBq2R_g2KdMsnN.EW0nHzbFRDjRRA79xwd8Ge3pHLn2QkJFUna7wjndG1VHb_. tLcaWq7GxzjPTtG61WwS7otm41ujJKuiz28OtY37vhFYATPkzDIdRXDl7vR484V6bK1OXE9WZ2uQ 0Cnl92vp1NI49VAJiWVPuCz.01LzLnClVPdfIVYRw1FBAixGc57uZy8zK6wCxN5FWZcJM5vhYzAB fI41o7heGRsKE4q6AEMujKimF61B5tm2z780knFAPKGhBQl8Jmf4LETzbGzxp5CB8Ga6GJSjHE5L FD9kbGQyeSIikMxs9_iWa_0ZfJfFCnbxQKLGhbox.7UQUCrAhhrHDHjKbqfYFSkVFpMH1j9BhJ6. 0g9qIDB5ZIO2lWaUZP2TYbZp3C3sT.hzuLV745uQqLE1PMmtUT6hoIvTi7zxCl4ISpKBqcEMQDT6 s_O7_1LxUxkNmLJzjl0tWOgkOZtZDApa7pY2wTae6tKlUS.xXKkLysL3xNas9pOb1Ixs_i.gEMzC u1IahtAvTdrqjU2GB0jsGE6G6z80iuidb0_ywlpl5lQee9iJr55njY0kZfC1uaPor50_vceo1FrB PznPGTiW30YRMWe_zx.5bVdH.g61r53E9qZ45ZUZMVDbNVnrsjU8xpXHh691oKI15wlKngqmsP1J S6386t8IhowgdGARZpdZOqlaRQhNBfitc6VaapXURgOdjOUfcSKRWcf8mJHg.HICiqPZO9UKXsZF hrcvwHTkAid8ltStoA7KzSeG1imhxxna2T3xg6GaMO1ggiOjdViSmClr1Wudcgv9Y89fO1_ne87E 1F7.mp16T4lipYrkcoNn4hgJ.b4H8bqU1Ca8Teg9j7NSNkto15bYumWUKpnwmzNUwjbn4KQSgZkB wwRxyYrYlnJ3GDsZ9zx2lPtwuKotmh2m7IfSg3CwX.sJlw63pfO17gYvJIX0TNGaMDHXcRO5Lpbu WuH0XAsRbdBsHddV.0X6eGrrwEDxoL0WXnYVXw3Qu9R0VYCm7f2TPMjZch6aZKHzNtUxFVVU7s_r uqD61rzh36iqnkzaW7ucfxOf7yVo.Kc1jOKXT Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Wed, 26 Feb 2020 17:03:37 +0000 Received: by smtp418.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 83f24b3b8b0e9039caa8051553f64758; Wed, 26 Feb 2020 17:03:33 +0000 (UTC) To: Tim Bruijnzeels Cc: sidrops@ietf.org References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> From: Stephen Kent Message-ID: <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> Date: Wed, 26 Feb 2020 12:03:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.15302 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 17:03:40 -0000 Tim, Thanks for your thoughtful analysis of the options. Her are some additional thoughts. In general, a stale CRL still represents the best info re revoked certs available to an RP, so ignoring it does not seem appropriate, to me. In the RPKI we also have Manifests, so if a Manifest is current but the CRL it references is stale, then that strongly suggests that the CA has encountered a problem generating a new CRL, but it's still the best revocation status info available, so use it and consider contacting the CA (via the GB record) to point out this problem. A CRL is invalid if it's signature doesn't verify, or if it has a syntax error, even in the face of a valid sig. In this case I would ignore the CRL contents, contact the CA, and keep using the freshest CRL the RP has. Because these CRLs MUST contain sequence numbers, receipt of a valid CRL that appears to be current, but has an older (or the same) serial number relative to a previously validated CRL is suspicious. I would definitively contact the CA to see if it just forgot to increment this field properly. I probably would stick with the freshest CRL info I had for that CA until the matter is resolved. There are more cases one can analyze, but I think the basic approach is to stick with prior, validated CRLs and contact the CA that issued the questionable CRL, until the matter can be resolved. As for the considerable leeway accorded to RPs in the Manifest document, I concur that it allows inconsistent local behavior. If the WG can agree on more proscriptive language, that would be good. When we wrote 6486 we were unable to agree on such, as we tried to balance robustness vs. responses to possible active attacks on repositories or communications between an RP and a repository. Steve From nobody Wed Feb 26 09:39:42 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75FF3A0D3A for ; Wed, 26 Feb 2020 09:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 RTidG0kKS_lZ for ; Wed, 26 Feb 2020 09:39:40 -0800 (PST) Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BABB3A0D39 for ; Wed, 26 Feb 2020 09:39:39 -0800 (PST) Received: by mail-wm1-f67.google.com with SMTP id p17so149093wma.1 for ; Wed, 26 Feb 2020 09:39:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=FgW+QJKFS8iYtdCkagWUE4oKsImfNpL44HQ0HeIEmbo=; b=X+9nBm7YXzQg/V2RA/lffgdK+1cNEjbJ21zmjhXuS14YMG8Rhn5tZKaGWkfL2zp5ZM 0SNrhfYazAUwKUNLXi3KlVffro08m9Y6SHv9J2WUctP8RszNyY22ABn11nqxIgioARxI j7a434Mbhc2jGPGnKk7mFsCU7j+tEusP3lXkVy/UVHsJcQIm1K0xtNuqWHUBYZblipFz g/xgol4SBUDP5oTpo31R/jGhCYAwu7VbP2eooUH72LNhlOK2QAr1GuPDWk9ajPP7u57a fl+6keFBRcTvV44PWPhEZ9O5knsGQibJ1FJMmXbWl0Z/UKs/y8hFOOnRMNxJtH/72qjc krAA== X-Gm-Message-State: APjAAAU+OBQxup6sirixmtDXgIpMrLVicd06iI/sxoNZn+YhaMYPLkcw p6MhrAfMXpbom1T4nBPjQ/hf4A== X-Google-Smtp-Source: APXvYqxS2YacoTBsvdGMrOR8GMHfbdi6JWi9H+KDgQoMMR6ZdV7opaCb05DwPOEg2vC+0T6tTqWcBg== X-Received: by 2002:a1c:960c:: with SMTP id y12mr6658372wmd.9.1582738777669; Wed, 26 Feb 2020 09:39:37 -0800 (PST) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id b7sm3636212wrs.97.2020.02.26.09.39.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Feb 2020 09:39:36 -0800 (PST) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 56d24ff9; Wed, 26 Feb 2020 17:39:36 +0000 (UTC) Date: Wed, 26 Feb 2020 17:39:35 +0000 From: Job Snijders To: Stephen Kent Cc: Tim Bruijnzeels , sidrops@ietf.org Message-ID: <20200226173935.GE72144@vurt.meerval.net> References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 17:39:42 -0000 On Wed, Feb 26, 2020 at 12:03:33PM -0500, Stephen Kent wrote: > As for the considerable leeway accorded to RPs in the Manifest document, I > concur that it allows inconsistent local behavior. If the WG can agree on > more proscriptive language, that would be good. When we wrote 6486 we were > unable to agree on such, as we tried to balance robustness vs. responses to > possible active attacks on repositories or communications between an RP and > a repository. Imagine a scenario where a money-in-the-middle (sic) strategically hides a select few ROAs, example: MITM shows rsync://rpki.ripe.net/repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/r7TSyWn_GbYPjNWvt4r5ewSNAsk.roa (80.128.0.0/11 AS 0 - expires July 1st, 2021) but hides rsync://rpki.ripe.net/repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/LkKeUPYrfgzjsOIejLjsHGk44cU.roa (80.128.0.0/11 AS 3320 - expires July 1st, 2021) If Origin Validating EBGP edge routers ends up honoring only a *subset* of VRPs, it may result in catastrophic hard-to-troubleshoot outages. In this example, the victim end up being unable to reach half of Germany. I think the entire repository should be considered invalid if a single file is missing but was referenced in the manifest. One can't produce rules based upon false or incomplete data, and one can't protect against hijacks using unsigned data. expired CRL? repository invalid any file missing that was referenced in manifest? repository invalid the above also means, is the CRL missing? repository invalid in addition to any cert being expired? underlaying objects invalid Any other behaviour is a security problem, unsafe. Leeway does more damage than good. I believe the premise for Origin Validation to work on the Internet it is that in order to get it deployed, BGP has to 'fail open', but in the RPKI cache validation process one must 'fail close', which depends on all validators being 'strict'. If the RPKI component doesn't fail closed, it produces false filters, which goes against our desire for BGP to be able to 'fail open'. Kind regards, Job From nobody Wed Feb 26 10:15:26 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3DB3A1071 for ; Wed, 26 Feb 2020 10:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 cFhwA92wnDUB for ; Wed, 26 Feb 2020 10:15:20 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 63FEA3A104A for ; Wed, 26 Feb 2020 10:15:20 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1j71DK-00019I-Eg for sidrops@ietf.org; Wed, 26 Feb 2020 18:15:18 +0000 Date: Wed, 26 Feb 2020 10:15:15 -0800 Message-ID: From: Randy Bush To: SIDR Operations WG References: <158274065310.22955.10729466847169070546.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 18:15:24 -0000 A new version of I-D, draft-ymbk-8210bis-00.txt has been successfully submitted by Randy Bush and posted to the IETF repository. Name: draft-ymbk-8210bis Revision: 00 Title: The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 Document date: 2020-02-26 Group: Individual Submission Pages: 37 URL: https://www.ietf.org/internet-drafts/draft-ymbk-8210bis-00.txt Status: https://datatracker.ietf.org/doc/draft-ymbk-8210bis/ Htmlized: https://tools.ietf.org/html/draft-ymbk-8210bis-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-ymbk-8210bis Abstract: In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. RFC 6810 describes version 0, and RFC 8210 describes version 1. This document updates RFC 8210. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Feb 26 14:35:56 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C601C3A09B2 for ; Wed, 26 Feb 2020 14:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.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 ycceIqApptkd for ; Wed, 26 Feb 2020 14:35:47 -0800 (PST) Received: from sonic312-21.consmr.mail.bf2.yahoo.com (sonic312-21.consmr.mail.bf2.yahoo.com [74.6.128.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1CE3A0995 for ; Wed, 26 Feb 2020 14:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1582756546; bh=A4mP3vBfuG9o7H15Th4vn8CLBPnUrp47qWHD/1LGaBE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=ZcXBmmtjlI3AK3kK/HC92xu+OO7ek1emHIL10bNhzyEZnrHfX6ND5221lfGpJTK8GJqjPwYGjhKxUtOg+B2eTY/vhnJQLd0DQbO+1xMoPGwl3J9ASJbHT4+8M6M37BoyVowdtwOnhhtZsv1e/LqsFeRnK9ErY3JKAeQWa+nwL9YoQXUpfNPxqniRmotZKZe4dKKmj9Zrc5Gywh4rfKSZcva98kmS7lDqMH/EY50vPu700FpCtz7u1USO0zJG1qvp8gOnHDpI7Js5c/28F6qoTNIqxhaeYNxVndApgn0RgOMYpvEcCQ+GxyyGu2PcPIdesOpyTjn4sihj4Ved2Kdukg== X-YMail-OSG: 5VzkOUUVM1lGGk71AY6zoS_qRsVmBZl7c.VVV8P6TKFLOgQX08HJ1u1vCJ6B6Do tOs0.4_GU1ArPv0slHOVywBrhwcjVflbQA4iWnjUhnj9bSjRL6a3Ov1RB.shMuoVWhEpbaIqVgFr Q8BW1Bx89n9o859IH5vfcnoZXTm4jfdWnaxzhebrXJENldsV.AtfoEE52jvUv0rrW_qASJmm_mQr qrF4aRZ24_GdBzHMv2778ui4vUCJlLR9bDCI6Vu8mykLtPlzeRh7QbLZoRpu4OB7u5DXmNnLVphT 2uitkx1JYHj2B1rX1DkfHGOabhkUPXEVPK2.1CnvQslPf9q6R.d1Fvl54bHeB2TVfXpybqRH1pXx iG4JLHz6G5V7eUSGuhi2buMGTEWT9yMKpERA5pNwMSXwVwXoJz7fYIn0RWzg676JBedi_CUIzQHK Nzv6NhlMJW1SfeZNDs6KrPdXxby5FhaR_H0lq2rWXnXdO6MD8dkp7fHy6ejxhJkvW4mh3kN_ui_S cieYmiB91lBUHYRSCwM7wqAixlw8Nz5RUOH264Vk9HDBCCtSaJPqxiYZCoeIv8MbvAU4WRkUyO73 frc_qkaoOMDo_pzBuJBtxEitXYzF.i5q.QJ3vdduFVNmnLqSt9oMVLNU9GeOZWe2sViLbzSQ5oha 1mWsg9XLB8.QrzT6rkxcs27LX2MlR8EWCbz4qksCxAoPbI4bHWePn.U2S2.ZrKVsnR9nPMHoAwc0 _jm3Dnv38wJPLCJh.Stv2gXDEmXCYuf19yxYN7F1bex_v.3ayarQEq7HPTJg8axVXWaAvIfX9JY5 aV2SWN.7aCXYiXvoug2rz7D0x_SGdA8eiGjrQV2npSSZkOAogyv9jK2ZLikj6ESIsjB38H.pR2So 5ZFVc1PAwgxDRS4MUKknGnUlSLvw829nZAhEAT.Xr.Km6gCIyP3YSRmmjadZrPZ049XMqzu_p5cL 41d.7nOWLA0Agm_1P5OxorTtmKclEmvW.IqXBcuU0vhKlpGONfNVpY5TtQbGDtOdjtS5GuyZcBoQ _7QSfgF93QqHv7eOJ31fV5DL1_4fUvk9i2aWUpDU_7MhLopsHotjSPeuJN37qDFb9nJNAgdiQZVR ItLzSu3BkzQvRgQw2.a65v7t0eZKMOf.lmipyUt3_Eligdm.uS7Vs1B3hk3Xz47zRV5U9eMnkAhn li7bSmhy1zVGc1xBoCfpLEZqnWcw8B6VJaMe_m0p2srOdOFvBJd2dH95Ae8JArOJP0._5vI3juu2 xzS7eMx.ms1XEm6Qg1X_Ae0fKvUM3kusRRX9eEmNEEIMRSCiPkyGrfLa5zpHmmdX.4LaWLjOPkeG RK6tlER2z9kGdkPao2QTAd3KU1NqVzUsMWHOpU9rHRUO3MC7A49QNFb2rMvxinM73n08dR.6z7Vv M6TxSBz7lLDzfjh2.5bqLpRlRjCTb73qKoVCs Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Wed, 26 Feb 2020 22:35:46 +0000 Received: by smtp426.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 60dcb33843dac545680354f568e4cedc; Wed, 26 Feb 2020 22:35:40 +0000 (UTC) To: Job Snijders Cc: Tim Bruijnzeels , sidrops@ietf.org References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> From: Stephen Kent Message-ID: Date: Wed, 26 Feb 2020 17:35:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200226173935.GE72144@vurt.meerval.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.15302 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 22:35:55 -0000 Job, > On Wed, Feb 26, 2020 at 12:03:33PM -0500, Stephen Kent wrote: >> As for the considerable leeway accorded to RPs in the Manifest document, I >> concur that it allows inconsistent local behavior. If the WG can agree on >> more proscriptive language, that would be good. When we wrote 6486 we were >> unable to agree on such, as we tried to balance robustness vs. responses to >> possible active attacks on repositories or communications between an RP and >> a repository. > Imagine a scenario where a money-in-the-middle (sic) strategically hides > a select few ROAs, example: > > MITM shows rsync://rpki.ripe.net/repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/r7TSyWn_GbYPjNWvt4r5ewSNAsk.roa > (80.128.0.0/11 AS 0 - expires July 1st, 2021) > > but hides rsync://rpki.ripe.net/repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/LkKeUPYrfgzjsOIejLjsHGk44cU.roa > (80.128.0.0/11 AS 3320 - expires July 1st, 2021) I'm confused by your example. The discussion has been focused on CRL issues, not suppression of ROAs. > If Origin Validating EBGP edge routers ends up honoring only a *subset* > of VRPs, it may result in catastrophic hard-to-troubleshoot outages. In > this example, the victim end up being unable to reach half of Germany. > > I think the entire repository should be considered invalid if a single > file is missing but was referenced in the manifest. One can't produce > rules based upon false or incomplete data, and one can't protect against > hijacks using unsigned data. Do you mean the pub point for the address space holder, vs. "the repository", which suggests a larger set of data, e.g., RIPE operates a repository that contains pub points for their members. > expired CRL? repository invalid > any file missing that was referenced in manifest? repository invalid > the above also means, is the CRL missing? repository invalid > in addition to any cert being expired? underlaying objects invalid > > Any other behaviour is a security problem, unsafe. Leeway does more > damage than good. I'm afraid I have to disagree with your conclusions., in  part because of confusing use of terminology. > I believe the premise for Origin Validation to work on the Internet it > is that in order to get it deployed, BGP has to 'fail open', but in the > RPKI cache validation process one must 'fail close', which depends on > all validators being 'strict'. If the RPKI component doesn't fail > closed, it produces false filters, which goes against our desire for BGP > to be able to 'fail open'. A goal RPKI operation is to not make routing worse that it would be in  the absence of the RPKI. Thus it seems appropriate to tolerate some types of operational errors, on a temporary basis, and try to follow up with CAs or pub point operators to resolve the errors. I acknowledge that different responses may be appropriate depending on  the nature of the error - a stales CRL is not the same as a bogus ROA. Steve From nobody Wed Feb 26 14:36:01 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313613A0971 for ; Wed, 26 Feb 2020 14:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.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 1cWVZ7OBVnsW for ; Wed, 26 Feb 2020 14:35:47 -0800 (PST) Received: from sonic312-21.consmr.mail.bf2.yahoo.com (sonic312-21.consmr.mail.bf2.yahoo.com [74.6.128.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0D53A096D for ; Wed, 26 Feb 2020 14:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1582756546; bh=A4mP3vBfuG9o7H15Th4vn8CLBPnUrp47qWHD/1LGaBE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=ZcXBmmtjlI3AK3kK/HC92xu+OO7ek1emHIL10bNhzyEZnrHfX6ND5221lfGpJTK8GJqjPwYGjhKxUtOg+B2eTY/vhnJQLd0DQbO+1xMoPGwl3J9ASJbHT4+8M6M37BoyVowdtwOnhhtZsv1e/LqsFeRnK9ErY3JKAeQWa+nwL9YoQXUpfNPxqniRmotZKZe4dKKmj9Zrc5Gywh4rfKSZcva98kmS7lDqMH/EY50vPu700FpCtz7u1USO0zJG1qvp8gOnHDpI7Js5c/28F6qoTNIqxhaeYNxVndApgn0RgOMYpvEcCQ+GxyyGu2PcPIdesOpyTjn4sihj4Ved2Kdukg== X-YMail-OSG: 5VzkOUUVM1lGGk71AY6zoS_qRsVmBZl7c.VVV8P6TKFLOgQX08HJ1u1vCJ6B6Do tOs0.4_GU1ArPv0slHOVywBrhwcjVflbQA4iWnjUhnj9bSjRL6a3Ov1RB.shMuoVWhEpbaIqVgFr Q8BW1Bx89n9o859IH5vfcnoZXTm4jfdWnaxzhebrXJENldsV.AtfoEE52jvUv0rrW_qASJmm_mQr qrF4aRZ24_GdBzHMv2778ui4vUCJlLR9bDCI6Vu8mykLtPlzeRh7QbLZoRpu4OB7u5DXmNnLVphT 2uitkx1JYHj2B1rX1DkfHGOabhkUPXEVPK2.1CnvQslPf9q6R.d1Fvl54bHeB2TVfXpybqRH1pXx iG4JLHz6G5V7eUSGuhi2buMGTEWT9yMKpERA5pNwMSXwVwXoJz7fYIn0RWzg676JBedi_CUIzQHK Nzv6NhlMJW1SfeZNDs6KrPdXxby5FhaR_H0lq2rWXnXdO6MD8dkp7fHy6ejxhJkvW4mh3kN_ui_S cieYmiB91lBUHYRSCwM7wqAixlw8Nz5RUOH264Vk9HDBCCtSaJPqxiYZCoeIv8MbvAU4WRkUyO73 frc_qkaoOMDo_pzBuJBtxEitXYzF.i5q.QJ3vdduFVNmnLqSt9oMVLNU9GeOZWe2sViLbzSQ5oha 1mWsg9XLB8.QrzT6rkxcs27LX2MlR8EWCbz4qksCxAoPbI4bHWePn.U2S2.ZrKVsnR9nPMHoAwc0 _jm3Dnv38wJPLCJh.Stv2gXDEmXCYuf19yxYN7F1bex_v.3ayarQEq7HPTJg8axVXWaAvIfX9JY5 aV2SWN.7aCXYiXvoug2rz7D0x_SGdA8eiGjrQV2npSSZkOAogyv9jK2ZLikj6ESIsjB38H.pR2So 5ZFVc1PAwgxDRS4MUKknGnUlSLvw829nZAhEAT.Xr.Km6gCIyP3YSRmmjadZrPZ049XMqzu_p5cL 41d.7nOWLA0Agm_1P5OxorTtmKclEmvW.IqXBcuU0vhKlpGONfNVpY5TtQbGDtOdjtS5GuyZcBoQ _7QSfgF93QqHv7eOJ31fV5DL1_4fUvk9i2aWUpDU_7MhLopsHotjSPeuJN37qDFb9nJNAgdiQZVR ItLzSu3BkzQvRgQw2.a65v7t0eZKMOf.lmipyUt3_Eligdm.uS7Vs1B3hk3Xz47zRV5U9eMnkAhn li7bSmhy1zVGc1xBoCfpLEZqnWcw8B6VJaMe_m0p2srOdOFvBJd2dH95Ae8JArOJP0._5vI3juu2 xzS7eMx.ms1XEm6Qg1X_Ae0fKvUM3kusRRX9eEmNEEIMRSCiPkyGrfLa5zpHmmdX.4LaWLjOPkeG RK6tlER2z9kGdkPao2QTAd3KU1NqVzUsMWHOpU9rHRUO3MC7A49QNFb2rMvxinM73n08dR.6z7Vv M6TxSBz7lLDzfjh2.5bqLpRlRjCTb73qKoVCs Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Wed, 26 Feb 2020 22:35:46 +0000 Received: by smtp426.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 60dcb33843dac545680354f568e4cedc; Wed, 26 Feb 2020 22:35:40 +0000 (UTC) To: Job Snijders Cc: Tim Bruijnzeels , sidrops@ietf.org References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> From: Stephen Kent Message-ID: Date: Wed, 26 Feb 2020 17:35:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200226173935.GE72144@vurt.meerval.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.15302 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 22:35:57 -0000 Job, > On Wed, Feb 26, 2020 at 12:03:33PM -0500, Stephen Kent wrote: >> As for the considerable leeway accorded to RPs in the Manifest document, I >> concur that it allows inconsistent local behavior. If the WG can agree on >> more proscriptive language, that would be good. When we wrote 6486 we were >> unable to agree on such, as we tried to balance robustness vs. responses to >> possible active attacks on repositories or communications between an RP and >> a repository. > Imagine a scenario where a money-in-the-middle (sic) strategically hides > a select few ROAs, example: > > MITM shows rsync://rpki.ripe.net/repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/r7TSyWn_GbYPjNWvt4r5ewSNAsk.roa > (80.128.0.0/11 AS 0 - expires July 1st, 2021) > > but hides rsync://rpki.ripe.net/repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/LkKeUPYrfgzjsOIejLjsHGk44cU.roa > (80.128.0.0/11 AS 3320 - expires July 1st, 2021) I'm confused by your example. The discussion has been focused on CRL issues, not suppression of ROAs. > If Origin Validating EBGP edge routers ends up honoring only a *subset* > of VRPs, it may result in catastrophic hard-to-troubleshoot outages. In > this example, the victim end up being unable to reach half of Germany. > > I think the entire repository should be considered invalid if a single > file is missing but was referenced in the manifest. One can't produce > rules based upon false or incomplete data, and one can't protect against > hijacks using unsigned data. Do you mean the pub point for the address space holder, vs. "the repository", which suggests a larger set of data, e.g., RIPE operates a repository that contains pub points for their members. > expired CRL? repository invalid > any file missing that was referenced in manifest? repository invalid > the above also means, is the CRL missing? repository invalid > in addition to any cert being expired? underlaying objects invalid > > Any other behaviour is a security problem, unsafe. Leeway does more > damage than good. I'm afraid I have to disagree with your conclusions., in  part because of confusing use of terminology. > I believe the premise for Origin Validation to work on the Internet it > is that in order to get it deployed, BGP has to 'fail open', but in the > RPKI cache validation process one must 'fail close', which depends on > all validators being 'strict'. If the RPKI component doesn't fail > closed, it produces false filters, which goes against our desire for BGP > to be able to 'fail open'. A goal RPKI operation is to not make routing worse that it would be in  the absence of the RPKI. Thus it seems appropriate to tolerate some types of operational errors, on a temporary basis, and try to follow up with CAs or pub point operators to resolve the errors. I acknowledge that different responses may be appropriate depending on  the nature of the error - a stales CRL is not the same as a bogus ROA. Steve From nobody Thu Feb 27 00:59:50 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AED3A1585 for ; Thu, 27 Feb 2020 00:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Q5arrSDwBuaz for ; Thu, 27 Feb 2020 00:59:47 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 D97B63A1549 for ; Thu, 27 Feb 2020 00:59:46 -0800 (PST) Received: from allealle.ripe.net ([193.0.23.12]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1j7F1E-0006Hr-MG; Thu, 27 Feb 2020 09:59:44 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::678]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from ) id 1j7F1E-0005cR-KI; Thu, 27 Feb 2020 09:59:44 +0100 To: Job Snijders Cc: sidrops@ietf.org References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> From: Robert Kisteleki Autocrypt: addr=robert@ripe.net; prefer-encrypt=mutual; keydata= xsBNBEzFa6gBCADVASYXBbUF7v1D+Y9XR41SEEMiZUARlUWeP0NrFHZmRRGdR5nM/p6HguUd StIPRmdqMdyLDqBsV8XPVu6lvhcb4+ZFu/V1XFPVyPBH8U6iQ4PdGDeqFlBm3gxoDOGraGw8 bjojvASTz/Wk3ddLPm34Kb6oMI2MclC016UgrPgIj6A1Uu8qQeBDyWrk+OrWUPOUOKM7QhQg cpU4JwuaesthFvqdoPNQJi9QUfn94r14ZNDYmeJlchZiRHWO70Gwoy3ywfAM9Kyi1tx78Qc9 E5ZhGIw9qqlzqa6c6a0qhup2Zh/dhVBJ05jCDN7bUQT5tRiOV2icyX8Dsr4KaWYCsAOVABEB AAHNMVJvYmVydCBLaXN0ZWxla2kgKFJJUEUgTkNDIGtleSkgPHJvYmVydEByaXBlLm5ldD7C wHgEEwECACICGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJWUwoeAAoJEC0ZXiKtTC3+ 04UH/jlvSR0esDGFSponUVawru+/QF61KdsNrdH6/Vs2buQvczW2Uh+S6Dic2vr2H0B1YrvL F2XpL2WJUHBUDLTA7dYTslvnHpyZrR8Sfb+h+wJ8OynxEC5wMKxfYNx2fMSk5EIU5mRjMaYg X/VkssDcoQAznNwVVYeqHYUJDMcrJhAYh44VHO208VwjPjHUDRlC+BoMGjHJnWDOAstlES8j 0r3adj2MqIHdDEjSdEx1+rbV0iZlgcDbYDex3qulOYlcZL+PJvGHzD6CkNBa8SbSN7cO0yqR OJ2sgobITOJ0GbRIbIvkUe1Iqw717CuQV/u822dFISDYOAhGYmfWGJWmkezOwE0ETMVrqAEI AKazZ2Agrv0nNFPWV69l6fEout/FaqWfyAG5V414l4yr+qVShUYzS+txA2vC+ouHvdORZ/JG xwKf6HE+YvvWS+Oa+b6h+GZfA3G43XGpQlxXrFK019TeMjhHqWprZALL4w2k6TatYT1ZW369 rORtwSgtn5ZC4uNcpZeDQddQvCjyYoknqlZqAFf1pssuGPTE8GvhrZGEp52dALYYoDIf7y/z 8fCAcy72rhMhQV02rPB49UxOEh2FZJhST0743tuMtFemBkp06B/Mcx54QT0muG8zj19oMDG3 AAaGjNP6B3qzR6F8VczR/qVhQzRvNMr8A6+y/ew/x4+48P+O/4n/I50AEQEAAcLAXwQYAQIA CQIbDAUCVlMKHgAKCRAtGV4irUwt/mvlB/sFID7mlsWAS66UyrI+tGs4Xfl59vvhRRZ4ZKiR 8VEbWbLKh/b9SoYcKt9SLEfVxJE5ebWPgIIvUSdLS6f4n9uAJteDZ4w/AVfp5a6jbfvMm7JP AMW4HtnZ3YbNevRgXdGVXN+bTLZzXoVijOKu+xHDBRNaUswaG3glrDJfUGkPQtCXFn6m6Pdw dW1/ShzwQgfuE/NXa83jhJ175P+NoQ2KG7934vu2MZdrtIqPibKuaGWMPG0L5YzPotK9ONmd taJMnuk92qqZ6S9JPwRZmogRW/sX54XvGg6RzNpdHS5C+iN01tCNJTRTlOJ1X73+RrGokvKc dp6fdfc4PHHhpcMd Organization: RIPE NCC Message-ID: <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> Date: Thu, 27 Feb 2020 09:59:43 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200226173935.GE72144@vurt.meerval.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-ACL-Warn: Delaying message X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274c44782414341e1a389c02d4e0a420707 Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 08:59:49 -0000 On 2020-02-26 18:39, Job Snijders wrote: > I think the entire repository should be considered invalid if a single > file is missing but was referenced in the manifest. One can't produce > rules based upon false or incomplete data, and one can't protect against > hijacks using unsigned data. I'm not sure that'd be wise. Knowing you're missing something does not invalidate the other bits that you can verify. Exactly what you keep using can depend on what's missing (a CRL, a CA cert, a ROA, ...) though. Regards, Robert From nobody Thu Feb 27 01:27:13 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AA33A1651 for ; Thu, 27 Feb 2020 01:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 ZUEt9Q97VAEb for ; Thu, 27 Feb 2020 01:27:09 -0800 (PST) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.10]) (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 7EA0A3A164F for ; Thu, 27 Feb 2020 01:27:09 -0800 (PST) Received: from [IPv6:2001:981:4b52:1:dc65:bf07:8257:debe] (unknown [IPv6:2001:981:4b52:1:dc65:bf07:8257:debe]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 4830B2DDE2; Thu, 27 Feb 2020 10:27:07 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1582795627; bh=Z2/lNHjVoHsP/QkxB0ilV0xZDFRMekrWxP1Tcelk7ww=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=sKF6xTjdfPBWSvMFhyUu8M2zNeLXhet5Gq2GDLum3PRiB363HHOoLr7J+Sxw68rs2 xrPCoxVrU0DMYL7BMxxVj0fkGkmsIF1X+UZWJaJ2x+I/qZxl9uOYBqJX56I0MTd5oW LEZrhVtNlRt1VSepStN9yGd5qosD7DjTS2NCsTf0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> Date: Thu, 27 Feb 2020 10:27:06 +0100 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> To: Stephen Kent X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 09:27:12 -0000 Steve, > On 26 Feb 2020, at 18:03, Stephen Kent = wrote: >=20 > Tim, >=20 > Thanks for your thoughtful analysis of the options. Her are some = additional thoughts. >=20 > In general, a stale CRL still represents the best info re revoked = certs available to an RP, so ignoring it does not seem appropriate, to = me. In general I agree. Which is why I mentioned the example of objects one = might find published outside of the context of the RPKI repository, and = *not* listed on a manifest. Such objects have yet to be invented but = theoretically one can think of signed structures under an existing RPKI = CA cert (e.g. using their own embedded EE) - which is shared out-of-band = between parties. > In the RPKI we also have Manifests, so if a Manifest is current but = the CRL it references is stale, then that strongly suggests that the CA = has encountered a problem generating a new CRL, but it's still the best = revocation status info available, so use it and consider contacting the = CA (via the GB record) to point out this problem. >=20 > A CRL is invalid if it's signature doesn't verify, or if it has a = syntax error, even in the face of a valid sig. In this case I would = ignore the CRL contents, contact the CA, and keep using the freshest CRL = the RP has. >=20 > Because these CRLs MUST contain sequence numbers, receipt of a valid = CRL that appears to be current, but has an older (or the same) serial = number relative to a previously validated CRL is suspicious. I would = definitively contact the CA to see if it just forgot to increment this = field properly. I probably would stick with the freshest CRL info I had = for that CA until the matter is resolved. >=20 > There are more cases one can analyze, but I think the basic approach = is to stick with prior, validated CRLs and contact the CA that issued = the questionable CRL, until the matter can be resolved. >=20 > As for the considerable leeway accorded to RPs in the Manifest = document, I concur that it allows inconsistent local behavior. If the WG = can agree on more proscriptive language, that would be good. When we = wrote 6486 we were unable to agree on such, as we tried to balance = robustness vs. responses to possible active attacks on repositories or = communications between an RP and a repository. What I am suggesting is that we *could* update 6486 and make validation = more restrictive regarding manifests: - all objects on a manifest must be present and accounted for (I agree = with Job regarding partial withhold attacks) - all objects on a manifest need to be validated - objects that are not on a manifest can be considered invalid This is in-line with the specifications defined in RFC 6481 (A Profile = for Resource Certificate Repository Structure), which essentially says = that all current objects must be published, and that no invalid objects = may be published. Then, if the manifest is already a signed statement of everything that = is current, at least regarding the currently defined object types, as = defined in RFC 6481, then what is gained by checking that CA was also = capable of generating a CRL - using the same authoritative key and = publication method - that confirms that the objects that are current = according to the manifest are indeed not revoked? Requiring the CRLs just feels like unnecessary brittleness to me (again = in the context of RFC 6486). It creates multiple loci for bugs in CA = implementations, and complicated error conditions that need to be = checked by RPs. This is what I meant with the perhaps poorly chosen word = 'pedantic'. Maybe I should have used the word 'redundancy'. Redundancy = may seem like a good idea in general, but in this case it really only = allows for the possibility of two conflicting signed messages. Thus it = seems that this does not increase security, but provides more ways for = things to break. Don't get me wrong.. we *are* generating the CRLs in unison with the = MFTs. And for this to change one would have to make update to the = manifest RFC and restrict the validation rules in a manner like I am = suggesting above. I am just asking that we consider that. Kind regards, Tim >=20 > Steve >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Feb 27 01:50:25 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073883A16BB for ; Thu, 27 Feb 2020 01:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 N_kScBSMMpxt for ; Thu, 27 Feb 2020 01:50:21 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 716313A16C3 for ; Thu, 27 Feb 2020 01:50:21 -0800 (PST) Received: from [IPv6:2001:981:4b52:1:dc65:bf07:8257:debe] (unknown [IPv6:2001:981:4b52:1:dc65:bf07:8257:debe]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 9DCE12DE3F; Thu, 27 Feb 2020 10:50:19 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1582797019; bh=NNSIgSba+MCgsUoQ2EFaYvXGaNitpdJU0YI6pCdjJ+U=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=o+U6UZ00wP9NG2uL5gQN29E+vPZuX9RrzbArx1RGgvS18OsPMOioTVs3TpKFNb6uH q23GaVcn/NiDBiyRgg9rTOzEI7B3/jG3Ra4i6wPaj6r6HR4lS/8A+B9HCiVoKjSegS h8cZ443dX/tx2QMb2yKrPWeJSJqepX4hJO3kFJg0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> Date: Thu, 27 Feb 2020 10:50:19 +0100 Cc: Job Snijders , sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl> References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> To: Robert Kisteleki X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 09:50:23 -0000 Hi, > On 27 Feb 2020, at 09:59, Robert Kisteleki wrote: >=20 >=20 >=20 > On 2020-02-26 18:39, Job Snijders wrote: >> I think the entire repository should be considered invalid if a = single >> file is missing but was referenced in the manifest. One can't produce >> rules based upon false or incomplete data, and one can't protect = against >> hijacks using unsigned data. >=20 > I'm not sure that'd be wise. Knowing you're missing something does not > invalidate the other bits that you can verify. Exactly what you keep > using can depend on what's missing (a CRL, a CA cert, a ROA, ...) = though. I am not saying that I have the complete answer here, but I think it's = worthwhile to discuss this further - if the WG is willing to consider = updates to the manifest RFC. It gets complicated. ROAs at the parent level have the ability to invalidate announcements by = children that run delegated CAs. If their CA cert is missing, then this = can impact ROV to the point that announcements by children are = considered invalid. In such cases it might be better to mark objects the ROA objects as = invalid so that ROV yields not found. It is probably okay to recurse any = other CA cert and use ROAs found under it. Probably, because probably = they are more specific, and ROAs there would not invalidate covering, = presumably, less specific announcements done by the parent (yes, lots of = assumptions here). For BGPSec certificates things get more complicated, = because at the MFT level they are indistinguishable from delegate CA = certificates. Also BGPSec does not have a soft-landing, so invalidating = certificates (rather than ROAs) might be quite harmful. Note, I think this should be applied only to *missing* objects as that = indicates either a failure to publish things properly, or possibly a = partial withhold attack where the RP receives incomplete information. = And even then, there may be ways to recover if an RP still has prior = copies of all missing objects (check hash). If objects are found and accounted for, but they turn out to be invalid, = then I believe that other objects should not be impacted. Regards Tim >=20 > Regards, > Robert >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Feb 27 10:27:20 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3EA3A0433; Thu, 27 Feb 2020 10:27:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Chris Morrow via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Cc: sidrops@ietf.org, nathalie@ripe.net, Nathalie Trenaman , iesg-secretary@ietf.org, sidrops-chairs@ietf.org Message-ID: <158282803376.2127.10288204422189210778.idtracker@ietfa.amsl.com> Date: Thu, 27 Feb 2020 10:27:13 -0800 Archived-At: Subject: [Sidrops] Publication has been requested for draft-ietf-sidrops-rp-06 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 18:27:19 -0000 Chris Morrow has requested publication of draft-ietf-sidrops-rp-06 as Informational on behalf of the SIDROPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ From nobody Thu Feb 27 10:32:58 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FC73A0845; Thu, 27 Feb 2020 10:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 H_EXPR9bOF7J; Thu, 27 Feb 2020 10:32:33 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6753A03EA; Thu, 27 Feb 2020 10:32:32 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id f3so369122qkh.3; Thu, 27 Feb 2020 10:32:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WsksHkyIy0qYw0a59jRsAexwqnM1E8mNSOSLn3KWy28=; b=PVsjMe2P0cJeFNtp+9QGQbRzeWAxwDB1ozQhyQsrFIDfBpX/psk4grwlsZ8curTMC7 lmpTFFCPJgH93snneVvTcitT6U6lm/hrGrvOi/KKWXu5VZ4zLVnDqoH9/QV7NHcRAoqI RSDsIdNlnY4uY9JA3SweeMcmQGrA3VUXf8Tguz3hbjda8lX9MScGZFVDL4CtUL2JxLWn UVHU1Kc/OWT1MqbNurkODg8b2YP9tCJQJRDRXZaa2ErwFYeD8IVyvIJVfO6eloSTWXX/ 9CsBzHdeigUaBObXOG8qSn4ttwthfw2kfKVQvXo34FiOnTTlKUbMO147Cz2gmfmE22p+ 2s/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WsksHkyIy0qYw0a59jRsAexwqnM1E8mNSOSLn3KWy28=; b=StcOyAbMTspm+djzdWF1lZX4TTgbH0SB4s5G3PzkVi996QvioEZlHw4n4XKlEPEu7p XQ2sPC4eTIP6dJU6YS9qX3dJqdLs07/K1O2Wn828jleJdJ+ud/W84Uk/9S+6kcLau2U5 TOfs52jWe/5Fy7WhBoQbcXsOzVIhDp2nZ0+0NW0f1t5gBK/fPLFK7Ps3tAotO5+mBPic tZq/1/Yd13h/H0WsdY8yat2nGT97JaDJTtt6DYHZBy0Jo31DeaSxMsZ5u+Af+LZczI2X 4EUpAhUi9TAij5gi4yIoGcBOj0EHokLWcU/gf/XWfc8uOPZ0xnMmwbEhfzwZ4fzF28vv E6PQ== X-Gm-Message-State: APjAAAWLARw2zn5rAkBk7GBWjxT5Yul5pc5aAhtlGRdvXkpg5NDVFYfd +7mTbadlseRMT4xp4xSPhrQ0SkJvjKfoSkM5z3PUXdya X-Google-Smtp-Source: APXvYqz1yGRvMoLIZSloo26ybjU5SMveZXL1PJElSj+mDOT/3MT7M1ZH4QN1epV2l1Evqihqxf+nh6e6VlHQG2q9b3I= X-Received: by 2002:a05:620a:222d:: with SMTP id n13mr733462qkh.268.1582828351318; Thu, 27 Feb 2020 10:32:31 -0800 (PST) MIME-Version: 1.0 References: <157914534015.22379.11024327123542212494@ietfa.amsl.com> In-Reply-To: <157914534015.22379.11024327123542212494@ietfa.amsl.com> From: Christopher Morrow Date: Thu, 27 Feb 2020 13:32:20 -0500 Message-ID: To: SIDR Operations WG Cc: i-d-announce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-05.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 18:32:41 -0000 Howdy WG Peepls! This document got marked somewhere in the datatracker as: "WGLC"... which seems awesome, but I didn't see/remember actually doing that :( Do the authors feel this document is ready for WGLC? If so we can get that started :) If not I'll go re-set the status in datatracker. On Wed, Jan 15, 2020 at 10:29 PM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIDR Operations WG of the IETF. > > Title : RPKI Signed Object for Trust Anchor Keys > Authors : Carlos Martinez > George G. Michaelson > Tom Harrison > Tim Bruijnzeels > Rob Austein > Filename : draft-ietf-sidrops-signed-tal-05.txt > Pages : 16 > Date : 2020-01-15 > > Abstract: > A Trust Anchor Locator (TAL) [I-D.ietf-sidrops-https-tal] is used by > Relying Parties (RP) in the RPKI to locate and validate a Trust > Anchor (TA) CA certificate used in RPKI validation. This document > defines an RPKI signed object for a set of Trust Anchor Keys (TAK), > that can be used by TA creators and publishers to signal their set of > current keys and the location(s) of the accompanying CA certificates > to RPs, as well as changes to this set in the form of revoked keys > and new keys, in order to support both planned and unplanned key > rolls without impacting RPKI validation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-signed-tal-05 > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-signed-tal-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-signed-tal-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Feb 27 14:31:17 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D793A0E4F for ; Thu, 27 Feb 2020 14:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com 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 Y-x1l8TDEGAw for ; Thu, 27 Feb 2020 14:31:04 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FFDB3A0DE5 for ; Thu, 27 Feb 2020 14:31:04 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id w9so1241703iob.12 for ; Thu, 27 Feb 2020 14:31:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sVne3KthjmiWuVL/CvB39fTaEy61aVP7nNpL+uf/F7Y=; b=POKXPGS6TtBIIel35e0IRZE2K6+wEFCQ4OFWGWHInRWOa7vG9MvpUwdi647enZR/Jm PZ2T/SjgZLMSozuTTfHJt1VXzlE9vUECSN1gS/evYRvunlE5qEUYXtnru1OXMt7N6lI8 wMd59+4LZ553chapsWM/o8Yp3ZYdP73dzxvQNn4DKZBC4lfoFa9OqxMtgbhVstKdskTD jiOg0H89AeLKrPsWJmClYu3q1wY4PiBMWWgg60ZGfU6iJ7teb6zIf/4MfGyheZO5OikU gbQu0LTskbMfVQNg1ZfAEkSPpa7Oh5bcZvYIocEsXCxPhamJiB0Na8CNXX3mRbDXcOXQ a+bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sVne3KthjmiWuVL/CvB39fTaEy61aVP7nNpL+uf/F7Y=; b=sOJNZhDRPDFrwB91hOwZdoamgY5r19dcxkrReQnvi9Pt1QwMSLZBYfa1cAD1keDowq MiLB0ZV9ETrfNsBhZCo4oY++rVy58kWLhZEzv1UpVYzjZFU3vOYyHFTmtswVeHwWYXDR cwt8sKHLjDNUhfIA1SCbDgZV0ctvS66mNUKdeYBOFYZoHC8ZPYX8iX4ZnQCM9PRxYeoQ 32+zyLypb3XJ9vG02KXnuV2WrQOkZ3TfozGRe/wVw1g41t+6TBsBi0F4HLlZt9aTqadF HOcrt3rPExa7Pr0GfyP4tAwN3Wmkjw/LsbTsrsw/WrmmpupzyxoX6lfFksXLGAV2AIiE i5uA== X-Gm-Message-State: APjAAAVIInSwsXcODJACbQM5n69ZMzye7JRAkMcKWbuRx946gmFYqd5r OIgKddzMGsN8PoDZz0MCYnksnyWpoEPvud2LsC+lAg== X-Google-Smtp-Source: APXvYqy2Sfx4QZZBW0sBrjGxQeMfrPnW2yBIbUDQq0/nePJ21456DhSX4NGi3lt2qwGSdVAQMD32nZSK6H4CHKBF0cg= X-Received: by 2002:a02:cba5:: with SMTP id v5mr937658jap.64.1582842663802; Thu, 27 Feb 2020 14:31:03 -0800 (PST) MIME-Version: 1.0 References: <157914534015.22379.11024327123542212494@ietfa.amsl.com> In-Reply-To: From: George Michaelson Date: Fri, 28 Feb 2020 08:30:52 +1000 Message-ID: To: Christopher Morrow Cc: SIDR Operations WG , i-d-announce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-05.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 22:31:16 -0000 I'd like it if we could go WGLC. I think it takes a stronger signal of commit and contentment in the WG. Our author discussion on "where next" is a bit cold right now, because there isn't much to do, but we don't have words for what there is to do. How about we put that to the ML or F2F? Which I guess, is what you just did. I stole the edit token. I'd be happy to let my esteemed co-authors and the WG tell me what they want here. Probably, confusion in my part put it to WGLC but if it is there, why don't we treat it seriously and ask if its ready? We need a mechanism to signal intent to change TAL. Automation is a "step too far" for some people, Rob Kisteleki has spoken to the inherent risks, and the concern it does not "fix" risks some people think it may, because an ability to subvert the TAL implies an ability to subvert the signature over the TAL, and so force communities to inherit a new TAL, of bad intent. The DNS root process with in-band signal is a different world. We can learn from it, but it may not show what general X509 PKI models think is a good way to do this. Rob suggested we consider why browsers ship TA changes by updating code. That moves the burden to a body who agrees what TAL need to be shipped, and liaison with the Validator authors and release processes. Or, a hand-run process to use this mechanism. Or, a signalling mechanism to flag "this TAL needs to change" but the actual decision to change, is hand-managed buy the RP. Basically, I don't know why it flagged WGLC but I think it is not far off, and I would like it to close. -G On Fri, Feb 28, 2020 at 4:33 AM Christopher Morrow wrote: > > Howdy WG Peepls! > This document got marked somewhere in the datatracker as: "WGLC"... > which seems awesome, but I didn't see/remember actually doing that :( > > Do the authors feel this document is ready for WGLC? If so we can get > that started :) If not I'll go re-set the status in datatracker. > > On Wed, Jan 15, 2020 at 10:29 PM wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the SIDR Operations WG of the IETF. > > > > Title : RPKI Signed Object for Trust Anchor Keys > > Authors : Carlos Martinez > > George G. Michaelson > > Tom Harrison > > Tim Bruijnzeels > > Rob Austein > > Filename : draft-ietf-sidrops-signed-tal-05.txt > > Pages : 16 > > Date : 2020-01-15 > > > > Abstract: > > A Trust Anchor Locator (TAL) [I-D.ietf-sidrops-https-tal] is used by > > Relying Parties (RP) in the RPKI to locate and validate a Trust > > Anchor (TA) CA certificate used in RPKI validation. This document > > defines an RPKI signed object for a set of Trust Anchor Keys (TAK), > > that can be used by TA creators and publishers to signal their set of > > current keys and the location(s) of the accompanying CA certificates > > to RPs, as well as changes to this set in the form of revoked keys > > and new keys, in order to support both planned and unplanned key > > rolls without impacting RPKI validation. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-sidrops-signed-tal-05 > > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-signed-tal-05 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-signed-tal-05 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Feb 28 10:22:32 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03E23A0DF6 for ; Fri, 28 Feb 2020 10:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com 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 qub-t6zLP427 for ; Fri, 28 Feb 2020 10:22:24 -0800 (PST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2069.outbound.protection.outlook.com [40.107.237.69]) (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 0CB1B3A1801 for ; Fri, 28 Feb 2020 10:22:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IeWNq1RCm74TDfWf5QBxHDZAX9aTe+8eqmlXN//JxST6n9/v1BJvaxoL+J7yHivBqixxTArDHjUFmEqJh0Ode8R1ZWSh+xvqWvSTlAMAZL8BO84pJNz3W2Y1ICF41YPgXLLSgoT3kE+TjaktEvK3GN96T5avuY3MyMtcmHCzKmUWtrhm8eog8zUXPb7W36U4nhbBafGN7cIpR29Cz8JYFuwH5QO38mgw+VT9PHJahrZFFzpjeJ19pnyCDnNC6rchQKsCRp7cKqPcB5XHpMgNW5SPGOdxuxDQaaZxxu9WS7LmfSuy/auZvUNCe2jzcBSnY+4mu8+QW9kITgjqbogSuQ== 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=m+cZMDFKcBjXRlFzTE0GPWyXFarcncmhyrnOxOx9ynI=; b=jSnT/dinR2P0tuSGWiQWttrxHdeevqUzmDSo800JaSblHyfDTSgkqLfm48fCm84OlumIowr7H9uGSoHNeV/tuda8SM+9kyEqzuDh7SPz2tKZK2OMNmcZ+Cbs/OQqw4Hmzu3uf8X5bTEFWFWTHFDXLcSxX16Y/GIpwwbMStJnb0DtnLaHkVUvz7X+4HyN6yI0cDHx0qab4xgRQlucdPNNw0sGCWn/XXeRDb2GTbyC/AR0CIg1NUAHt6qypIc47Dd0gFRNH2Z8EYp48CrC2xIsK6aToi6Wc34ksA2qjVRuPuMz0JCx8Q3QJpe19MxrrmlvjMp9GE/0y+nCfTOF4ho4Cw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m+cZMDFKcBjXRlFzTE0GPWyXFarcncmhyrnOxOx9ynI=; b=irA5+ukZrr75JhF8Dw+0ufCjrDdYLJ6A2RQVz4NDatQ0bCmfmtsHzurr2yHGh445cgXFOxZTCXDu8HYMLfk0xgMmHlmnaMUe69p7hMAomejzsn+p7BL8Ua0U1wWXydzIipz+DXLOy+cYJdlk4Yy91Lxwkwnh0BYD7x7Lm4ZZe4Q= Received: from BYAPR18MB2856.namprd18.prod.outlook.com (2603:10b6:a03:10e::30) by BYAPR18MB2710.namprd18.prod.outlook.com (2603:10b6:a03:102::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Fri, 28 Feb 2020 18:22:19 +0000 Received: from BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::9ca8:5fd:8296:7b05]) by BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::9ca8:5fd:8296:7b05%4]) with mapi id 15.20.2750.021; Fri, 28 Feb 2020 18:22:19 +0000 From: Keyur Patel To: SIDR Operations WG Thread-Topic: IETF107 -- Vancouver -- Call for Agenda Items Thread-Index: AQHV7mQCby0jewrflEypj6tUTtqHLQ== Date: Fri, 28 Feb 2020 18:22:18 +0000 Message-ID: <0B777C6F-2BE1-43F0-9F69-3044C6294ADE@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [70.234.233.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0257fd92-ed72-4d92-38d4-08d7bc7b256e x-ms-traffictypediagnostic: BYAPR18MB2710: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0327618309 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39830400003)(366004)(376002)(346002)(396003)(199004)(189003)(4744005)(81156014)(81166006)(5660300002)(8676002)(186003)(316002)(2616005)(9326002)(86362001)(6506007)(26005)(8936002)(33656002)(71200400001)(66446008)(2906002)(76116006)(64756008)(478600001)(66556008)(6916009)(6486002)(36756003)(66476007)(6512007)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2710; H:BYAPR18MB2856.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zgg+EEcFxDRF0TmWlzr7MjvQ+t808KV1qcplG38SPy4s/n8XPyGr05lQ3egUSoW1cmFxVTj05kvCqcKbOcNLWR1akXLMxyPHa+tq95YvnHpbThhXtUsMOdr0IxGq2NZEm4EloixyAy90TSNqLP5ci5KL7xF54vQLiFs3KqYXg7chAUGD7JDrcVvPTifX8G4NJEN3dj9lKfQJQaWNqaDQabFq10UEHkw8J9kOwHbgxu54KWEuajyLnE0Yjl1IR1AaCCbWSrPBrp1t3Hyg/GjD60xRIz8qbFUxi5ohFnZ4YgKwh3sdw6DonYaqNcEE9ssfEbBs89xgeM4TV7PXTy8liAJtHD1KdOP6Z3CdLm6f2jOZR/mQlRsxmggyHuWTEXMR/HURTejYM9SffIpSpoH4qoYvautsSVAYIdu3VuRhxpQcRrPZgUWuix7Ws8kFHg5c x-ms-exchange-antispam-messagedata: mq1sE5YXdJ/Ho8i7ayEnpeJsigpSTyCG8Y5/DiByCoHjzeqssWERO3TK0lrwA89FTNLcrSiEKZx5tyUEVcuLbhy7Uwz7dcfs0Pb1u8MiWiDYj8ycczYRtJ0VSjCwJhOUwm1XAj7c8Spc4NkWPV42kQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_0B777C6F2BE143F09F693044C6294ADEarrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0257fd92-ed72-4d92-38d4-08d7bc7b256e X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2020 18:22:18.9475 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EQESiu5L2baCINu5lej7BLg1ZrfOnNons8imYBdX+z453umVcAY5q8nCWbA6mHfZQaoCaINE9sQVQiwzqOW3iA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2710 Archived-At: Subject: [Sidrops] IETF107 -- Vancouver -- Call for Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 18:22:30 -0000 --_000_0B777C6F2BE143F09F693044C6294ADEarrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRm9sa3MsDQoNClNJRFJPUFMgd2lsbCBtZWV0IGF0IElFVEYxMDcgb24gRnJpZGF5LCBNYXJj aCAyN3RoIGZyb20gMTI6MjAgcG0g4oCTIDE6NTAgcG0uIFBsZWFzZSBmb3J3YXJkIGFueSBTSURS T1BTIGFnZW5kYSBpdGVtcyB5b3UgbWF5IGhhdmUgdG8gTmF0aGFsaWUsIENocmlzLCBhbmQgbWUu IFBsZWFzZSBhbHNvIG1ha2Ugc3VyZSB0aGF0IHlvdXIgc2xpZGVzIGFyZSBhdmFpbGFibGUgYnkg RnJpZGF5IG1vcm5pbmcgKDMvMjAvMjAyMCkuIFNsaWRlcyByZWNlaXZlZCBhZnRlciB0aGUgZGVh ZGxpbmUgbWF5IG5vdCBiZSBhdmFpbGFibGUgZm9yIHVzZSBkdXJpbmcgdGhlIG1lZXRpbmcuDQoN ClJlZ2FyZHMsDQpOYXRoYWxpZSwgQ2hyaXMsIGFuZCBLZXl1cg0KDQo= --_000_0B777C6F2BE143F09F693044C6294ADEarrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <45B1604FA5D22C4EAE54070C5893AC8C@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3 MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPkhpIEZvbGtzLDwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjpibGFjayI+U0lEUk9QUyZuYnNwO3dpbGwgbWVldCBhdCBJRVRGMTA3IG9uIEZyaWRheSwg TWFyY2ggMjc8c3VwPnRoPC9zdXA+IGZyb20gMTI6MjAgcG0g4oCTIDE6NTAgcG0uIFBsZWFzZSZu YnNwO2ZvcndhcmQgYW55Jm5ic3A7U0lEUk9QUyZuYnNwO2FnZW5kYSBpdGVtcyZuYnNwO3lvdSBt YXkgaGF2ZSB0byBOYXRoYWxpZSwgQ2hyaXMsIGFuZCBtZS4gUGxlYXNlIGFsc28gbWFrZSBzdXJl IHRoYXQNCiB5b3VyIHNsaWRlcyBhcmUgYXZhaWxhYmxlIGJ5IEZyaWRheSBtb3JuaW5nICgzLzIw LzIwMjApLiBTbGlkZXMgcmVjZWl2ZWQgYWZ0ZXIgdGhlIGRlYWRsaW5lIG1heSBub3QgYmUgYXZh aWxhYmxlJm5ic3A7Zm9yJm5ic3A7dXNlIGR1cmluZyB0aGUgbWVldGluZy48L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 YmxhY2siPlJlZ2FyZHMsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6YmxhY2siPk5hdGhhbGllLCBDaHJpcywgYW5kJm5ic3A7S2V5dXImbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0B777C6F2BE143F09F693044C6294ADEarrcuscom_-- From nobody Fri Feb 28 11:04:56 2020 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677713A19DF for ; Fri, 28 Feb 2020 11:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com 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 fBQDYULBHQzi for ; Fri, 28 Feb 2020 11:04:52 -0800 (PST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2068.outbound.protection.outlook.com [40.107.93.68]) (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 B389B3A0772 for ; Fri, 28 Feb 2020 11:04:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W3LC/6fsOSH8yQ6BIFu7mLKSfBkhtJmseAhy04MQkRYc/pxfcu7ZrUwA0ELaP8oaouVZMy1SWxjOnk4AHChVaPmG06bmvug+9x1dpIlFEQgOIoJl9lZIZYa6WB58SBnCnoHGIb+/mE6XMEEV47LI3wiME6rK4f6zLHZYWEKY6Ze52Dv4/1n7QgSnpckOwL8aTjPMtSjJoPWS7AeDDyHRo6WfWHpZbJ+LRoNQ1DX3T455WyGkJEINAgwsRyTb4UxlLQ5nYizs+2a0jml+sSg80Xn1bXU1nJoVQi/hIXaP6p8W02lrIcbEbn1nh7p3opwVIrwQApgk6fjoGGJ1j6TXIg== 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=tA0gCDKFSMUZndXbQKwtjq1WknH343g8sne3dPhepLo=; b=OLpQNPcVcfwEsumvRMwFUKOMEVaJetk48LKmrIWnpHxWOPAhw/Ex6RL5N6MlEJMuIYQtMukpEkXlgKqa6U3i43PELXe67iLKukmLhajV0D4e2k+ilOXDiCZoUNBRjoopinuab5K5xkGnq6cPcks9gQqnloOWgUh+X3mfS8OduxHOoOs69sdj60qgGUqhtou2LyUlP5FZWzJDPfhFPnHNxbTtknf8mgP0sEWbB9w7ceyMkPaqSKXMPbYIBTZeKe/8/o6T4+yZm0giEJCzl4yurOlphg4uQSEKhxreCI60F+k3NexsOiRN44q7HGyR2o5J4ZkGzeQSpEkD0m/J24j8qg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tA0gCDKFSMUZndXbQKwtjq1WknH343g8sne3dPhepLo=; b=IFX/VzVtl1pumOigQIWleTfX6eGZDdU66aDYn8RsK/jk/HtZDKlcYtEhjNsFCfWLq6+W39UXvr2KqMV2j4SqBz0fst6oK3cu4fPAOsRQUti1oc5ODQzguSWlWch9deyyClgls2N1wjJhrULJF55IYyw5VA/RJ1LshsbAiyIR5C8= Received: from BYAPR18MB2856.namprd18.prod.outlook.com (2603:10b6:a03:10e::30) by BYAPR18MB2503.namprd18.prod.outlook.com (2603:10b6:a03:135::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.16; Fri, 28 Feb 2020 19:04:49 +0000 Received: from BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::9ca8:5fd:8296:7b05]) by BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::9ca8:5fd:8296:7b05%4]) with mapi id 15.20.2750.021; Fri, 28 Feb 2020 19:04:49 +0000 From: Keyur Patel To: SIDR Operations WG Thread-Topic: draft-ietf-sidrops-ov-egress-00.txt Thread-Index: AQHV7mnyFDFnNKKHdE+n7XkoPg/QLQ== Date: Fri, 28 Feb 2020 19:04:49 +0000 Message-ID: <9A83B679-263C-4333-A04E-6AF8F80B3A7D@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [70.234.233.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c3d83bfb-462d-4a2e-73dd-08d7bc81158e x-ms-traffictypediagnostic: BYAPR18MB2503: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-forefront-prvs: 0327618309 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(136003)(366004)(39830400003)(346002)(189003)(199004)(186003)(5660300002)(2906002)(316002)(26005)(33656002)(6506007)(4743002)(81156014)(8936002)(81166006)(8676002)(6916009)(6486002)(64756008)(66556008)(558084003)(478600001)(86362001)(71200400001)(2616005)(66446008)(6512007)(36756003)(76116006)(66946007)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2503; H:BYAPR18MB2856.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WsbEgXEgel9fSoj/fh+UIDxXNYJKm2fXlWHgwV4Zk280H3EHtNiy1YFiDKIBWLc514L+wKvTmSnQveJvbTHg5sDXWJFijx4cEf2+KJFrjW/CL7Rtn0rmzKpYBtabKryrYIyWYtuXi0uJba/vuFiNAThmGPcENvAayJ42Fjm+313dxlUdZPo3QALk5z1/MBE119junpMTKsSgrc1tE/dL9NCcKtlQ3lvTX57fgJq267egwPPSzwXCubLT1K/ZqzCzamQMKTKo9OyXoxqOHnvXxOCzqKbPKQbbxl2PBknKAObrWPrv627udvJB3tNt5e0hWughgsjvv8S81tFee2PC/NBtoyy9/txQZodbeAeFjGiPlwgdl8PcMdj8dggry7VIWa8AgEqRHCUEdhrN653Fg8pijSSELZCEHGx3Vlg4e1XuWi5yIFw642KBp8HjBi6w x-ms-exchange-antispam-messagedata: ZPGJpb/H7vc6GEHPVXvLytFgViJ6uWB8BjibiqW3+rHwxEG1jNy/dKmgQn51U+OkWSKmQbdx3cQJXh+OM/rKK3hMtO2hJWaHr1YeDX+FatVMLvDJvVSRSmjkKiaDegaPEjaTOCzx2469GRi9mtgo8A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <9AE028DCCDAB3D42B526C408D0F07387@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: c3d83bfb-462d-4a2e-73dd-08d7bc81158e X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2020 19:04:49.3135 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aXI2O1f6vknPRsRia8dbAPsoXuP4lICaM39QSHN7yFwbBhPKaC6UwDIsexurfpEFRmyRk6TSb8n0Zgv3LR9CZA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2503 Archived-At: Subject: [Sidrops] draft-ietf-sidrops-ov-egress-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 19:04:55 -0000 Rm9sa3MsDQoNCkFzIGEgZG9jdW1lbnQgc2hlcGhlcmQgZm9yIGRyYWZ0LWlldGYtc2lkcm9wcy1v di1lZ3Jlc3MtMDAudHh0IEkgd291bGQgbGlrZSB0byBrbm93IGlmIGFueW9uZSBpcyBhd2FyZSBv ZiBhbnkgaW1wbGVtZW50YXRpb25zIGZvciB0aGlzIGRyYWZ0Pw0KDQpSZWdhcmRzLA0KS2V5dXIN Cg0K77u/DQogICANCg0K From nobody Fri Feb 28 14:36:27 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A313A1F73; Fri, 28 Feb 2020 14:35:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: warren@kumari.net, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292930432.19931.12775795478095938220@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:04 -0800 Archived-At: Subject: [Sidrops] sidrops - Requested session has been scheduled for IETF 107 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:12 -0000 Dear Nathalie Trenaman, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sidrops Session 1 (1:30 requested) Friday, 27 March 2020, Morning Session II 1220-1350 Room Name: Plaza B/C size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/sidrops.ics Request Information: --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Nathalie Trenaman Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 70 Conflicts to Avoid: Chair Conflict: 6man idr grow lsvr rtgwg lsr mpls pim spring v6ops People who must be present: Keyur Patel Chris Morrow Warren "Ace" Kumari Resources Requested: Special Requests: ---------------------------------------------------------