Re: [saag] Discuss at SAAG? was Re: nation state crypto profiles - draft-jenkins-cnsa-cmc-profile-00

Eric Rescorla <ekr@rtfm.com> Thu, 04 October 2018 04:45 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F423130DDF for <saag@ietfa.amsl.com>; Wed, 3 Oct 2018 21:45:11 -0700 (PDT)
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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 YcW_L9UG3CYo for <saag@ietfa.amsl.com>; Wed, 3 Oct 2018 21:45:08 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 A55DF130DD5 for <saag@ietf.org>; Wed, 3 Oct 2018 21:45:07 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id t22-v6so5763690lfb.7 for <saag@ietf.org>; Wed, 03 Oct 2018 21:45:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9r73Pf2XlG2EPKNWMemRoQ7HTdbmOfS8tYfDF+ApuZo=; b=fLLnfWKIScLoTjf2uTxb9k1IkBsyXqiOMlUdCw/n9IOq5c6oPrNa8M34elPPREPSO/ DpylKTuyCINEifL8H4S+oukRIAddkfJ7IZpq8JW9Vdt6iYSUUAH7jIb3wFNLv4TjhrKU Q+fzDMLpUIEmb67u2L+F0Wbv/Yzhh6XrCG2xubHLr4gDfcput97TRV7IkCTAxGdsTw+g EjTSrIxPM45rbsR2sSXkiF4pJPY0bbH1oQuMdBTHh4oVI9vx0bu1248sU9GQ3PcKCzgJ 2X9k/t8bXnszoVGEyVzIF9aZPzZ/DBuwrJfjSECR/p0jzv28/8Enci/bNno7qFNeo9s3 iZgA==
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=9r73Pf2XlG2EPKNWMemRoQ7HTdbmOfS8tYfDF+ApuZo=; b=bA3JpCCPUPu0/mAXdwpZE1Sjm2a7O4kDWmClhEIIJGKlhn/OzrwOrjfqo024cmDSlj AOT1dn4bUa9tQUmMUrmo7SaOhrIxqTTYzdM8nOW+/+KiQ7wLroZtG99BJYcdvMVJK+OP bi0CSZR8L3oLlPmRJwXgGIPWUumE0sfv4anlFruBorhoF0UrzYNrqWYQJCeZnd0NHcm7 873WgmjmUrSUUgCdITCrq+f30q/E9tAcBAORqjhjnFJe0APNHU9DrFQliMstMKnLnXE3 rnSQ7ZBBCWPlSywEK/W41n+7DSxpvadSJLgadI/CUkHwOu49edeqPT8f4hKlZ7hXizZJ 6dNg==
X-Gm-Message-State: ABuFfojJ1+V6P6ZDZI1CADz6NqmE2IxEKgSt9J7Vyoo8ClBELrR43vpJ bPAdMXbOmDXujWMA/I9Ep1jnLxo4jUxzC969fgZi/Q==
X-Google-Smtp-Source: ACcGV61yJk7hp0Y+uLMOfuZdpmAa5qoq1/eAv1sLn8eoWgRI+vEnhOl0gYtgdOrT0/+BGa7jS9d6cj1COlSHiiMs7cQ=
X-Received: by 2002:a19:a90f:: with SMTP id s15-v6mr2543588lfe.154.1538628305735; Wed, 03 Oct 2018 21:45:05 -0700 (PDT)
MIME-Version: 1.0
References: <7CB10AE4-09C1-4AC5-B255-6489EF1FAE78@akamai.com> <alpine.LRH.2.21.1810021734350.12702@bofh.nohats.ca> <BEC2489D-FE1E-4E55-A88C-05E0143F8415@gmail.com> <20181002220720.GD56675@kduck.kaduk.org>
In-Reply-To: <20181002220720.GD56675@kduck.kaduk.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 03 Oct 2018 21:44:29 -0700
Message-ID: <CABcZeBPJjfjdxbHCWFQFLJcnMKZSCpVb0oEZPhpymVgu-=bspQ@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Yoav Nir <ynir.ietf@gmail.com>, Paul Wouters <paul@nohats.ca>, saag@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009ae65505775fd1ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/9VONQpaTXj3pMfEVk33xLE9NoUo>
Subject: Re: [saag] Discuss at SAAG? was Re: nation state crypto profiles - draft-jenkins-cnsa-cmc-profile-00
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Oct 2018 04:45:11 -0000

On Tue, Oct 2, 2018 at 3:07 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> On Wed, Oct 03, 2018 at 01:02:55AM +0300, Yoav Nir wrote:
> >
> >
> > > On 3 Oct 2018, at 0:36, Paul Wouters <paul@nohats.ca> wrote:
> > >
> > > On Tue, 2 Oct 2018, Salz, Rich wrote:
> > >
> > >> *  (e.g. TLS ciphersuites identifiers) to use them for national-wide
> purposes
> > >> *  along with "first class" algorithms.
> > >> TLS has moved to “doc required”  Not “RFC required.”  And added a
> column that says whether it is “recommended” or “no comment.”  This seems
> like it will work out well.
> > >
> > > Similarly, for IKE/IPsec, the IANA registries are Expert Review, not
> "RFC required”
> >
> > Right. So if SAAG (or the IESG) can guide the designated experts about
> national crypto, that would be great.
> >
> > Suppose (and this is just an example) the Russian government would like
> to use TLS 1.3 with the Kuznyechik cipher. This is assuming that it has an
> AEAD mode defined, so it can be used. They have several options:
> > They can publish a document on gostperevod.com <http://gostperevod.com/>
> and ask IANA to register the Kuznyechik AEAD in the TLS registries.
> > They can publish a draft (in addition to #1) and then ask IANA to
> register the Kuznyechik AEAD in the TLS registry while asking the RFC
> editor to publish.
> > The can publish on gostperevod.com <http://gostperevod.com/> and tell
> everyone to squat on (0x13, 0x79)
> >
> > I think we can all agree that #3 is a bad outcome, but that is what they
> will do if IANA won’t allocate identifiers.
> >
> > IMO #1 is good enough, provided we can get guidance from SAAG or the
> IESG to recommend such registration.
> >
> > It should be noted that a line should be drawn somewhere. I think a
> nation state with serious cryptographers such as Russia should get a code
> point for its national crypto.  I think someone who has come up with a
> great new algorithm that he totally cannot break should not get a code
> point. Somewhere between these two extremes the line should be drawn. The
> question is where?
>
> That's a question for the corresponding registry's Designated Experts,
> presumably.  RFC 8447 gives guidance to the experts (for the ciphersuite
> registry):
>
>    Note:  The role of the designated expert is described in RFC 8447.
>       The designated expert [RFC8126] ensures that the specification is
>       publicly available.  It is sufficient to have an Internet-Draft
>       (that is posted and never published as an RFC) or a document from
>       another standards body, industry consortium, university site, etc.
>       The expert may provide more in-depth reviews, but their approval
>       should not be taken as an endorsement of the cipher suite.
>
> which seems to push the Experts towards being pretty generous about
> approving codepoint requests.  I would be surprised if #1 above was
> controversial (but, to be clear, would welcome a conversation with the
> experts if needed; I'm not trying to force anyone's hand).
>

Speaking as an individual, not AD.

My understanding of the intent of the current rules for TLS was to grant
code points as long as there was a document describing the cipher suite,
even if the DEs thought the algorithms were silly or potentially insecure.

The reasoning here was that having code points marked Not Recommended was
better than having people squatting.

-Ekr


> -Ben
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>