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
>>
>
>