Re: WG Review: CURves, Deprecating and a Little more Encryption (curdle)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 07 December 2015 17:38 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A391AD087 for <ietf@ietfa.amsl.com>; Mon, 7 Dec 2015 09:38:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 gM2EV-AnsFwR for <ietf@ietfa.amsl.com>; Mon, 7 Dec 2015 09:38:37 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82EFB1AD082 for <ietf@ietf.org>; Mon, 7 Dec 2015 09:38:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5E69DBE4C; Mon, 7 Dec 2015 17:38:35 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTavj1yQJz-r; Mon, 7 Dec 2015 17:38:35 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 741F7BE49; Mon, 7 Dec 2015 17:38:34 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449509915; bh=in0TVeAwN1QQVuNQesNIUqIv+VaNzfQkfV1TEv05mTM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=bcSR2kYi8bqryVebkIQ2qTdH3jitLtcpWgIhHgJGMzAM483+M3SkugGHOqwNmvXRt ovL1gGMvZNmSRjvFMNU1EIc+uYgKMLosK/3WkxXaQLElR2OwHOjShhoIbi6jWpj/f6 9BjpUPlIZnSF5ModiKU4VG5eS7EHhuRDfnZSGXa4=
Subject: Re: WG Review: CURves, Deprecating and a Little more Encryption (curdle)
To: Phillip Hallam-Baker <phill@hallambaker.com>
References: <20151204170507.5160.44472.idtracker@ietfa.amsl.com> <56656C43.5070501@alvestrand.no> <56656DD2.9010609@cs.tcd.ie> <CAMm+LwhfJGvE-LvxJwRzRHjpcohQtSnhodF5a7rmbh_Foc5fBw@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <5665C419.6060201@cs.tcd.ie>
Date: Mon, 07 Dec 2015 17:38:33 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <CAMm+LwhfJGvE-LvxJwRzRHjpcohQtSnhodF5a7rmbh_Foc5fBw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/ffVbD7mSjSHfzM18tA8UuiWKZZw>
Cc: Harald Alvestrand <harald@alvestrand.no>, IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2015 17:38:40 -0000

Hiya,

On 07/12/15 16:44, Phillip Hallam-Baker wrote:
> On Mon, Dec 7, 2015 at 6:30 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
> 
>>
>> Hiya,
>>
>> On 07/12/15 11:23, Harald Alvestrand wrote:
>>> I think there's a piece of backstory here I'm not getting....
>>>
>>> Den 04. des. 2015 18:05, skrev The IESG:
>>>> The protocols in scope are Secure Shell (SSH), DNSSEC, PKIX, CMS, XML
>>>> Digital Signatures and potentially Kerberos and JSON.
>>>
>>> Why is TLS not included?
>>>
>>> It seems likely that the answer is one of:
>>>
>>> 1) TLS is already up-to-date in the space this group is limited to
>>> 2) TLS work is being done in the TLS working group
>>
>> The latter, and a bit of the former:-)
>>
>>>
>>> In both cases, it would be nice to say so in the charter.
>>
>> The charter text tries to do that generically but does mention
>> TLS specifically in this bit:
>>
>>   "Where there is an IETF working group or area group with expertise in
>>    a relevant topic the CURDLE working group will defer to the
>>    consensus of the more specific working group as to where work will
>>    be done. For example, the TLS, OpenPGP and IPSECME WGs are actively
>>    considering some of these topics. "
> 
> 
> 
> That being so, I suggest adding S/MIME to the scope:

CMS is in scope and noted as such. If more drafts are needed though
then folks would need to write those soonish, assuming we end up with
consensus for a short-lived WG.

> 
> * S/MIME has approximately the same number of public certs issued as there
> are registered OpenPGP keys.
> * The number of government certs is probably the same again and they are
> more active.
> * The current state of S/MIME crypto is 3DES.
> 
> Yes, S/MIME is built on CMS but there is a little bit more. In particular
> the only channel you have to advertise the algorithms supported is through
> the cert chain. There is mechanism described in RFC2633, RFC6277 and
> RFC6664 but how pervasive is deployment and do all the parts join up?
> 
> I don't want us to be in a position where we find we need just a little bit
> of glue to make the system work and these are out of scope.
> 
> A similar issue occurs in SSH. Right now, managing SSH keys is a real PITA
> because the configuration tools all use keys rather than fingerprints of
> keys. Even though they all present fingerprints to the user when connecting
> to a new server.
> 
> A lot of these fingerprints are based on SHA-1 and while it might well be
> the case that collision attacks don't really matter, having to explain that
> repeatedly is an ongoing cost. And further, we can't rip SHA-1 or MD5 out
> of the crypto libraries as long as that type of vestigial application
> persists.
> 
> I would like us to have a common format for presenting fingerprints of keys
> across applications and at minimum use that for both SSH and OpenPGP.

I would also like that but a) I don't think it's for curdle and b) while
it'd be good, we (IETF) never seem to quite manage to avoid doing those
in protocol-specific ways.

The reason I don't think it fits curdle is that it's not only a
crypto algorithm - the hash input is the real issue there and that's
not in scope as far as I can see.

But if many folks wanted it, I'm sure they'd speak up now.

> In general we should attempt to converge on a single set of algorithm
> choices for all IETF protocols unless there are really good reasons to do
> something different. In particular we should really try to make sure that
> OpenPGP and S/MIME can both use the same set of algorithms. Right now we
> have a situation where S/MIME has the deployment advantage. If people want
> to get more OpenPGP deployment they should try to eliminate all unnecessary
> differences between the two systems. Having them use a common set of crypto
> algorithms is a good start, at that point the only difference between the
> systems is key infrastructure and message format.
> 
> What is most frustrating about the current situation is that we have the
> same round of bikeshedding among the same set of people every time a new
> security WG starts. Introducing the new CFRG curves is a good opportunity
> to change that.
> 
> 
> It probably makes sense to write the charter in such a way that the group
> can consider recommendations for any IETF protocol that doesn't have an
> active WG and any active WG can delegate the issue to them.
> 
> I can't see much chance CURDLE comes up with consensus for a set of
> algorithms that isn't acceptable to TLS. If that happened the WG has
> failed. So the TLS chairs might as well consider CURDLE to be a way to take
> default algorithm choices off their plate.

Sure, if the TLS folks wanted the work to happen in the curdle WG
that'd be no problem. I don't believe that is actually the case
though, at least for TLS codepoints. (The PKI stuff needed for TLS
does fit curdle for sure.)

Cheers,
S.