Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-01.txt
Christopher Morrow <christopher.morrow@gmail.com> Thu, 26 July 2018 14:02 UTC
Return-Path: <christopher.morrow@gmail.com>
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 AC22B131001 for <sidrops@ietfa.amsl.com>; Thu, 26 Jul 2018 07:02:55 -0700 (PDT)
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_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 MoVqFcBTweP9 for <sidrops@ietfa.amsl.com>; Thu, 26 Jul 2018 07:02:47 -0700 (PDT)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 D897E130E70 for <sidrops@ietf.org>; Thu, 26 Jul 2018 07:02:46 -0700 (PDT)
Received: by mail-ua0-x22b.google.com with SMTP id i4-v6so1144057uak.0 for <sidrops@ietf.org>; Thu, 26 Jul 2018 07:02:46 -0700 (PDT)
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=I1d3gpupeYx4pidVGcS0trVOLVj6EGBTl61B8rAWg5g=; b=kq42/yoOalCKQP1Xek0DJc+I0/eW/cmYCbjexOA0jLVKa+nnNoFbgznREED1uMOcTQ EWaxvOYN62RTwQzopA9+9WhJDTitD4Yqvu5gFg/PixZ7HMSNTVApOU1QbqRcVfXjUrrd JaFvb7uWcyifMm8BmzGwIsfyP1GjrPGZjWm4l0LCl+GHlcSPSZt44rMHJVUPTkyGh6+J t6+4Wgo6L1sir2J5rEDH8/fyDfVh9wvOfB4RmauHEy8OTT8TFjlz40JfzfVF+9dxPqC5 92sMZorrHgt1h6IuDS8QIzSUK/IrD8p6dTDKlhJNn+P2NrVTbLV5FXZqlgR2BSuV02/y UsHw==
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=I1d3gpupeYx4pidVGcS0trVOLVj6EGBTl61B8rAWg5g=; b=A2yNK2J8XguUlNsbRU+ShbnriB4sfYo4jeDuMG/hSkq+ChxZfc3vnMykJFhzl4lMJK E7chgUCckoP0qJWsVBgTC6Ti185zxDrk0qvjHxKCa/Xf/N5/NbxeiWfPcLBkoUWZPJte fNFs/MnjIrsTSscPrGx8lzjyX2xfqnpHht9tJHGB2LDT6R69+/KTYbSJ9UFAQimSbrEJ hEFEkKMC3EpI/7eus2xyW3eTfFOMUvOcdqSlTnrzg4unkSaFNX3RXFjXW958jwTKd5vY 48NslNUnmcoUqewYSXA/JORugEZthZY9eqvFPFqFqsfkZI4T0V69xvrTuus76sqort1E gilw==
X-Gm-Message-State: AOUpUlE+EM96PrGsKNMU980ch3XJMl1IzJCjD8Y71qL6YvcAuQVGeeRQ zbo+oJ28tkCVyChvgtq5gClKHkyHqr3SKNuvkuLyPw==
X-Google-Smtp-Source: AAOMgpeaJR7XKiB96J6fAox00m53XUwNEmc+4kIEUpP2kF1cFdMz1IwMjUgZxGXhUr0cxQbe9Yb0OX8x6F+XcE3za2A=
X-Received: by 2002:ab0:74d1:: with SMTP id f17-v6mr1410468uaq.105.1532613765695; Thu, 26 Jul 2018 07:02:45 -0700 (PDT)
MIME-Version: 1.0
References: <152846464123.15396.14579027912013078144@ietfa.amsl.com> <20180717165827.GA14191@tomh-laptop> <AFFC2E31-6D59-4B21-A69F-A596BDA1B28D@nlnetlabs.nl> <CAL9jLaapseQt5jLE36s9BtoxYNptxeDJ3t4AG57U9Mkie_ESXA@mail.gmail.com> <2D133A87-A328-4758-9452-929370F8F54E@nlnetlabs.nl>
In-Reply-To: <2D133A87-A328-4758-9452-929370F8F54E@nlnetlabs.nl>
From: Christopher Morrow <christopher.morrow@gmail.com>
Date: Thu, 26 Jul 2018 10:02:34 -0400
Message-ID: <CAL9jLabJPe=yrADJ-cvaB5GtVcxS2UwUxHqKg7PefY8+Y5AqOQ@mail.gmail.com>
To: tim@nlnetlabs.nl
Cc: tomh@apnic.net, sidrops@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001510bf0571e773ac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/6LuANLk-aTNTPWh1JYtNlg6R5Ws>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-01.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jul 2018 14:02:56 -0000
On Thu, Jul 26, 2018 at 3:34 AM Tim Bruijnzeels <tim@nlnetlabs.nl> wrote: > Hi Chris, > > The last call was on 'draft-ietf-sidrops-https-tal-03’, see: > https://www.ietf.org/mail-archive/web/sidrops/current/msg00440.html > > There was a nit and a suggestion for clarification by Job Snijders that I > would be happy to include in an update. > > The signed-tal document needs more work. I received useful feedback on > list from Tom Harrison and Di Ma, and a good in-depth discussion with Rob > Austein. I plan to upload a new version for further discussion in the > coming weeks. > > ok, great, you intend to ask to move it back through wglc when you get settled then? (which is fine for me) > Tim > > > > > On 26 Jul 2018, at 08:02, Christopher Morrow <christopher.morrow@gmail.com> > wrote: > > It occurs to me that ... we should have closed out the wglc for this > document prior to IETF week. > If this set of comments/edits is all done then we can send a new version > of the draft and forward things up the mgmt chain. > > thoughts? > > -chris > > On Tue, Jul 17, 2018 at 5:52 PM Tim Bruijnzeels <tim@nlnetlabs.nl> wrote: > >> Hi Tom, >> >> Thanks for testing and the feedback. Comments below. >> >> > On 17 Jul 2018, at 12:58, Tom Harrison <tomh@apnic.net> wrote: >> > >> > On Fri, Jun 08, 2018 at 06:30:41AM -0700, internet-drafts@ietf.org >> 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 TAL >> >> Authors : Tim Bruijnzeels >> >> Carlos Martinez >> >> Filename : draft-ietf-sidrops-signed-tal-01.txt >> >> Pages : 12 >> >> Date : 2018-06-08 >> > >> > I've updated our proof-of-concept to match the new draft. Some >> > questions and minor suggestions: >> > >> > In section 3, there is: >> > >> > The ASN.1 syntax for the Signed TAL eContent defined in >> > Section 3.2. (This is the payload that specifies the AS being >> > authorized to originate routes as well as the prefixes to which >> > the AS may originate routes.) >> > >> > The text in parentheses looks to be a cut-and-paste from the ROA >> > profile document (RFC 6482). >> >> Fixed in my edit buffer. >> >> > In section 4, there is "[t]his EE certificate MUST have a 'notAfter' >> > time that reflects the intended time that this Signed TAL will be >> > published", which on its face implies that the 'notAfter' should be >> > set to the time when the object is first published. Changing it to >> > "reflects the intended time [or duration] for which this signed TAL >> > will be published" should make things clearer. >> >> Yes, you are right. The intention was duration. Fixed in the edit buffer. >> >> > >> > The SubjectPublicKeyInfo in the TAL structure has the type IA5String. >> > Is there some reason not to use the 'raw' SubjectPublicKeyInfo type >> > from RFC 5280? >> >> This is an oversight. It should just be the raw DER structure. >> >> > Since activationTime is not needed for an in-protocol reason at the >> > moment, it would be good to add a note to the draft that it's there to >> > prompt discussion/feedback about future dating. >> > >> > On future dating more generally, I think it's a good idea, since it >> > allows for in-band signalling about the rollover and would (hopefully) >> > encourage a wider set of users to test the new tree before it becomes >> > the 'official' tree. >> >> The current draft assumes that the TA tests things before publishing the >> new signed TAL object, and then I think it would be okay for RPs to follow >> this new TAL as soon as it’s available. >> >> But.. there may be good reasons for future dating / having a backup key. >> >> In that case I would suggest that we have a structure where the ‘current’ >> TA key and URIs are always listed explicitly, pretty much like the document >> says now, but there is an optional similar structure with the intended >> ‘activationTime’ (informational only) for the new key. >> >> That way the roll can be prepared in advance. RPs could theoretically >> verify independently that things are okay - but I would like to avoid >> putting this burden on all RPs. Once things are okay to roll, the TA can >> update it’s signed TAL then to make the new key ‘current’ and RPs can >> follow. >> >> As I said at the mic HSMs can be used to protect against key theft. But >> keys (or card sets) can still be lost. If access to the new key is lost, >> then the TA can just choose not complete the roll - remove it, replace it >> with a new target key. If access to the current key is lost, then things >> get more difficult. Then the new key would have to be allowed to take over, >> e.g. automatically once the activation time is past? >> >> Explicit revocation of the old key is also possible, but would require >> that RPs constantly check these candidate keys. I am afraid this adds a lot >> of overhead. >> >> Comments and ideas are most welcome! >> >> Tim >> >> >> >> >> >> >> > >> > -Tom >> > >> > _______________________________________________ >> > 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 >> > >
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-sign… Di Ma
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-sign… Tim Bruijnzeels
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-sign… Tim Bruijnzeels
- [Sidrops] I-D Action: draft-ietf-sidrops-signed-t… internet-drafts
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-sign… Di Ma
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-sign… Tom Harrison
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-sign… Tim Bruijnzeels
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-sign… Christopher Morrow
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-sign… Tim Bruijnzeels
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-sign… Christopher Morrow
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-sign… Tim Bruijnzeels