From william.polk@nist.gov Mon Nov 14 13:43:26 2011 Return-Path: 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 1F27811E8100; Mon, 14 Nov 2011 13:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH0rNqk9WOfk; Mon, 14 Nov 2011 13:43:25 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 036D211E80FB; Mon, 14 Nov 2011 13:43:25 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 14 Nov 2011 16:43:19 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 14 Nov 2011 16:43:22 -0500 From: "Polk, William T." To: "saag@ietf.org" , "secdir@ietf.org" , "privacydir@ietf.org" Date: Mon, 14 Nov 2011 16:38:50 -0500 Thread-Topic: Meeting on Privacy-Enchancing Cyrptography: Dec 8-9, 2011 Thread-Index: Acyi2ZH/n8Sl1c/cTRSiJ2hP8952JAAPDpR4 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: [saag] FW: Meeting on Privacy-Enchancing Cyrptography: Dec 8-9, 2011 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 21:43:26 -0000 FYI - I thought this meeting at NIST would be of interest to some on these lists. Thanks, Tim Polk ________________________________________ From: Caswell, Sara J. Sent: Monday, November 14, 2011 9:27 AM To: Polk, William T. Subject: Meeting on Privacy-Enchancing Cyrptography: Dec 8-9, 2011 Meeting on Privacy-Enhancing Cryptography: "Working with encrypted data without decrypting" December 8-9, 2011 NIST Gaithersburg, Maryland USA This workshop will discuss how modern cryptographic techniques can help protect privacy in an environment where many players are collaborating and competing as consumers and producers of digital goods and services. Among the discussion topics are medical databases, on-line auctions, privacy-friendly smart-meters, and identity management as envisioned by the National Strategy for Trusted Identities in Cyberspace. The target audience is industry, the research and academic communities, and Government. Registration Fee: $165.00 USD (Registration deadline December 1) Additional details can be found at: http://www.nist.gov/itl/csd/ct/pec-workshop.cfm From hallam@gmail.com Tue Nov 15 09:17:09 2011 Return-Path: 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 7CBDF1F0C38 for ; Tue, 15 Nov 2011 09:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.457 X-Spam-Level: X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9qhRcZJYXLM for ; Tue, 15 Nov 2011 09:17:05 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6D821F8B23 for ; Tue, 15 Nov 2011 09:17:01 -0800 (PST) Received: by faap16 with SMTP id p16so779797faa.31 for ; Tue, 15 Nov 2011 09:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=9X8ShNJHVmiMGAW2Zga5mhLaR8BJ4AGVKC2dQsRrbUw=; b=EQMlUDH/yyygqsRmH1R64jzrkBqPq7/VtMm1UPdONWFg5es21i8KuklgCPlOkKeToy 1b1XuK3Q/2kcNOpOI+IesWehBYA4gD6a7nEkQ5RldubwKYNEzag5LM54Wihoj2AG4Swp 7pLRY2A8Q8Q7RG7gKG9bR6xxIr2qXaIKsXgmw= MIME-Version: 1.0 Received: by 10.182.152.65 with SMTP id uw1mr6239704obb.10.1321377420001; Tue, 15 Nov 2011 09:17:00 -0800 (PST) Received: by 10.182.42.99 with HTTP; Tue, 15 Nov 2011 09:16:59 -0800 (PST) Date: Tue, 15 Nov 2011 12:16:59 -0500 Message-ID: From: Phillip Hallam-Baker To: saag@ietf.org, Sean Turner , Stephen Farrell Content-Type: multipart/alternative; boundary=f46d0444ef03bbc20404b1c927ad Subject: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 17:17:09 -0000 --f46d0444ef03bbc20404b1c927ad Content-Type: text/plain; charset=ISO-8859-1 This issue keeps coming up. I think that events are converging in a way that forces us to finally do something. At present the IETF has some tens of protocols that use cryptographic algorithms. Some use one registry, others use another, some use no registry at all, some use OIDs and so on. I see the following problems with the current situation: 1) There is no established process for telling people 'do not use 512 bit RSA keys with any IETF protocol.' We have recently had some issues arising from use of 512 bit certificates. This is a problem that should never have occurred. Browser vendors and CAs have both known of the security issues relating to 512 bits for a decade. But we still managed to end up with breaches occurring because everyone was waiting for someone else to take action. Some party needs to take action here and say that they are going to decide when to tell people to stop using obsolete crypto. The actual advice given being much less important than the decision to take responsibility for giving it. Remember that using stronger cryptographic algorithms DOES NOT make you any more secure. The only way to make yourself more secure is to STOP USING the insecure ones. Phasing out MD4 and MD5 is much more important than deploying support for the SHA-2 replacement. 2) There is no process for maintaining algorithms after a WG has closed. At one point quite a few Security Area groups appeared to be kept going more or less for the sole purpose of twiddling crypto algorithms. At the moment the IETF has a process for setting minimum key lengths for PKIX certs. But when PKIX closes the only mechanism will be a personal submission to change a standard developed by the WG for over 15 years. That seems to be a mismatch to me. 3) Duplication of effort. What point is served by having the same conversation about which algorithms to use in 10 different WGs? Modern machines are (mostly) pretty capable and there are almost no cases where an individual WG need be making protocol specific choices of algorithm to meet performance or space goals. Back in 1995 we had to consider performance quite closely. 512 bit certs actually made some sense at that point. We did not have AES. We were dealing with the FBI and part of the NSA trying to prevent use of strong crypto. Choice of algorithm was a much harder choice then and often had to be fitted to the specific protocol. Today there are still circumstances where performance constraints are significant. For example, the low performance devices I work with in my control systems work. But that means a choice between public key and symmetric key rather than between standards based crypto and some purpose built homebrew scheme. For most low performance devices, AES is now the algorithm preferred over all others because it is available in hardware. We are going to have to have a conversation about which algorithms we are going to choose somewhere. At the moment we face the choice of either have that conversation in Jose and then have it again in the next WG or have the discussion at a Security Area level and re-use those choices in the future. 4) Inconsistency Using two different crypto algorithms provides the strength of the weakest one. Inconsistency is almost always worse than a sub-optimal choice. I don't much care what the RSA signature format used is as long as it is 'good enough' for me and 'everyone' is using it. We should make these choices once and have the consequences flow out to all the protocols that use the algorithms. There have been a few prior attempts to deploy a registry that would cover more than one protocol. But to date there has been no registry that has really done what is needed to unify all the registries into one place and establish a unified process for change control. 5) 'Vanity' Crypto and other non-Mandatory algorithms. Cryptography has always been a highly politicized technology. In recent decades it has been as highly politicized as nuclear power and for much the same reason: Cryptography was one of the principle technologies that decided the outcome of WWII and was thus a key technology in the cold war. The politics behind so-called vanity crypto are very complex and I don't really want to go into them here. What I wat to do instead is to build a firewall so that the IETF does not need to get dragged into those politics. For historical reasons, the IETF preferred algorithms are essentially the NSA/NIST choices. One approach would be for the IETF to only recognize those and no others. This is probably not sustainable. Registries such as IANA are only stable so long as they are willing to register code points on a basis that is acceptable to the parties that need code points to be defined. If IETF/IANA refuses to assign code points then the refused parties will simply pick a code point and use it. This has occurred repeatedly in other venues. That is why there is a hole blocked out in the MAC address space, the storage providers wanted a globally unique address and saw no reason to pay IEEE for the numbers. That is why barcodes are structured as they are. Another approach is simply first come first served. I do not like that approach as it means that the IETF ends up 'endorsing' the use of broken crypto. But it is arguably better for the IETF to have a policy that allows for anyone to register in a way that ensures that a disclaimer is applied than to try to weed out the bad ones and not do a good job of it. One caveat that comes up is that some protocols have limited space for code points. But this can almost certainly be dealt with by some form of extension mechanism that allows use of a common code space (e.g. OIDs) for non mandatory to implement algorithms. Thus my proposal (which I will write up as an ID if people like the approach). IETF requests IANA create three new registries of cryptographic algorithms as follows: 1) Registry of Cryptographic Algorithm Identifiers. This would be a registry that is divided up into separate sub-registries for various types of algorithm (public key signature, public key encryption, digest, encryption, mac, suites, etc.) The criteria for inclusion would be expert review and RFC required. The RFC would start off with a pre-amble that states that the IETF makes no endorsement of the strength of the cryptographic algorithm and the expert review would be strictly limited to determining that the format of the document is correct, the document would not be allowed to specify code either. The purpose of these requirements being to prevent people from presenting assignment of code points as an IETF endorsement of the algorithm strength. The document would be required to: 1) Specify the code points for ASN.1 OID, text string, URI and optionally additional code points for IPSEC, DNSSEC, etc. 2) Specify test vectors in a format that ensures that endian-ness issues are addressed. 3) Specify the location where further documentation is to be found (which might be another RFC). 2) Registry of Mandatory to Implement Algorithms This would be a subset of the algorithms specified in the first registry and would normally consist of exactly one algorithm of each class. Criteria for changes would be Standards Action required. Each RFC making changes would specify the full list of required algorithms each time. Specifying compliance with this would be separate from specifying compliance with the base specification. So if a vendor was specifying standards compliance for its Web server it would specify 'Complies with RFC 2616, RFC 5246 & RFC XXXX' 3) Registry of Deprecated Algorithms. This is the registry of algorithms and key sizes that IETF warns against using. The warning may be immediate or have some specific action date. It would also be possible to state that an algorithm is deprecated for specific purposes or with certain protocols. For example, MD5 should not be used for any purpose that requires protection against collision attack. There are certainly cases where use of MD5 does not raise a security issue, though the cost of going through the necessary justification is almost never going to be worthwhile unless there is a major legacy deployment issue. Criteria for changes would be Standards Action required. This would also be cumulative. To be in compliance with this specification, applications MUST NOT permit the use of those algorithms (even if the user requests them). So to specify compliance, a product would state 'Complies with RFC 2616, RFC 5246, RFC XXXX & RFC YYYY' The task of ongoing maintenance would be left to the IETF SAAG and SECDIR. Actually making these decisions is much less difficult than deciding on having one place to make them. Although the bar is set at 'standards action required', this would normally be something I would see being done on an individual submission basis rather than requiring a Working Group to be formed. -- Website: http://hallambaker.com/ --f46d0444ef03bbc20404b1c927ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This issue keeps coming up. I think that events are converging in a wa= y that forces us to finally do something.

At prese= nt the IETF has some tens of protocols that use cryptographic algorithms. S= ome use one registry, others use another, some use no registry at all, some= use OIDs and so on. I see the following problems with the current situatio= n:


1) There is no established process for t= elling people 'do not use 512 bit RSA keys with any IETF protocol.'=

We have recently had some issues arising from use= of 512 bit certificates. This is a problem that should never have occurred= . Browser vendors and CAs have both known of the security issues relating t= o 512 bits for a decade. But we still managed to end up with breaches occur= ring because everyone was waiting for someone else to take action.

Some party needs to take action here and say that they = are going to decide when to tell people to stop using obsolete crypto. The = actual advice given being much less important than the decision to take res= ponsibility for giving it.

Remember that using stronger cryptographic algorithms D= OES NOT make you any more secure. The only way to make yourself more secure= is to STOP USING the insecure ones. Phasing out MD4 and MD5 is much more i= mportant than deploying support for the SHA-2 replacement.


2) There is no process for maintaining a= lgorithms after a WG has closed.

At one point quit= e a few Security Area groups appeared to be kept going more or less for the= sole purpose of twiddling crypto algorithms. At the moment the IETF has a = process for setting minimum key lengths for PKIX certs. But when PKIX close= s the only mechanism will be a personal submission to change a standard dev= eloped by the WG for over 15 years. That seems to be a mismatch to me.


3) Duplication of effort.

=
What point is served by having the same conversation about which= algorithms to use in 10 different WGs? Modern machines are (mostly) pretty= capable and there are almost no cases where an individual WG need be makin= g protocol specific choices of algorithm to meet performance or space goals= .

Back in 1995 we had to consider performance quite close= ly. 512 bit certs actually made some sense at that point. We did not have A= ES. We were dealing with the FBI and part of the NSA trying to prevent use = of strong crypto. Choice of algorithm was a much harder choice then and oft= en had to be fitted to the specific protocol.

Today there are still circumstances where performance c= onstraints are significant. For example, the low performance devices I work= with in my control systems work. But that means a choice between public ke= y and symmetric key rather than between standards based crypto and some pur= pose built homebrew scheme. For most low performance devices, AES is now th= e algorithm preferred over all others because it is available in hardware.<= /div>

We are going to have to have a conversation about which= algorithms we are going to choose somewhere. At the moment we face the cho= ice of either have that conversation in Jose and then have it again in the = next WG or have the discussion at a Security Area level and re-use those ch= oices in the future.


4) Inconsistency

Using two different crypto algorithms provides the strength of the weakes= t one. Inconsistency is almost always worse than a sub-optimal choice. I do= n't much care what the RSA signature format used is as long as it is &#= 39;good enough' for me and 'everyone' is using it.

We should make these choices once and have the conseque= nces flow out to all the protocols that use the algorithms.

<= /div>
There have been a few prior attempts to deploy a registry that wo= uld cover more than one protocol. But to date there has been no registry th= at has really done what is needed to unify all the registries into one plac= e and establish a unified process for change control.


5) 'Vanity' Crypto and other non= -Mandatory algorithms.

Cryptography has always bee= n a highly politicized technology. In recent decades it has been as highly = politicized as nuclear power and for much the same reason: Cryptography was= one of the principle technologies that decided the outcome of WWII and was= thus a key technology in the cold war.

The politics behind so-called vanity crypto are very co= mplex and I don't really want to go into them here. What I wat to do in= stead is to build a firewall so that the IETF does not need to get dragged = into those politics.

For historical reasons, the IETF preferred algorithms a= re essentially the NSA/NIST choices. One approach would be for the IETF to = only recognize those and no others. This is probably not sustainable. Regis= tries such as IANA are only stable so long as they are willing to register = code points on a basis that is acceptable to the parties that need code poi= nts to be defined. If IETF/IANA refuses to assign code points then the refu= sed parties will simply pick a code point and use it. This has occurred rep= eatedly in other venues. That is why there is a hole blocked out in the MAC= address space, the storage providers wanted a globally unique address and = saw no reason to pay IEEE for the numbers. That is why barcodes are structu= red as they are.

Another approach is simply first come first served. I d= o not like that approach as it means that the IETF ends up 'endorsing&#= 39; the use of broken crypto. But it is arguably better for the IETF to hav= e a policy that allows for anyone to register in a way that ensures that a = disclaimer is applied than to try to weed out the bad ones and not do a goo= d job of it.

One caveat that comes up is that some protocols have li= mited space for code points. But this can almost certainly be dealt with by= some form of extension mechanism that allows use of a common code space (e= .g. OIDs) for non mandatory to implement algorithms.



Thus my proposal (which I will write up as= an ID if people like the approach).

IETF requests IANA create three new registries of cryptographic algorithms = as follows:

1) Registry of Cryptographic Algorithm Identifiers.

This would be a registry that is divided up into separate sub-registries fo= r various types of algorithm (public key signature, public key encryption, = digest, encryption, mac, suites, etc.)

Th= e criteria for inclusion would be expert review and RFC required.=A0
<= div style=3D"color: rgb(34, 34, 34); font-family: arial, sans-serif; font-s= ize: 13px; background-color: rgba(255, 255, 255, 0.917969); ">
Th= e RFC would start off with a pre-amble that states that the IETF makes no e= ndorsement of the strength of the cryptographic algorithm and the expert re= view would be strictly limited to determining that the format of the docume= nt is correct, the document would not be allowed to specify code either. Th= e purpose of these requirements being to prevent people from presenting ass= ignment of code points as an IETF endorsement of the algorithm strength.

The document would be required to:

1) Specify the code points for ASN.1 OID, text string, URI and optionally a= dditional code points for IPSEC, DNSSEC, etc.
2) Specify test vectors in a format that ensures that endian-ness issues ar= e addressed.
3) Specify the location where further documentation is to be found (which m= ight be another RFC).

2) Registry of Mandatory to Implement Algorithms

This would be a subset of the algorithms specified in the first registry an= d would normally consist of exactly one algorithm of each class.=A0

Cr= iteria for changes would be Standards Action required. Each RFC making chan= ges would specify the full list of required algorithms each time.

Specifying compliance with this would be separate from specifying complianc= e with the base specification. So if a vendor was specifying standards comp= liance for its Web server it would specify 'Complies with RFC 2616, RFC= 5246 & RFC XXXX'


3)= Registry of Deprecated Algorithms.

Th= is is the registry of algorithms and key sizes that IETF warns against usin= g. The warning may be immediate or have some specific action date.

It would also be possible to state that an algorithm is deprecated for spec= ific purposes or with certain protocols. For example, MD5 should not be use= d for any purpose that requires protection against collision attack. There = are certainly cases where use of MD5 does not raise a security issue, thoug= h the cost of going through the necessary justification is almost never goi= ng to be worthwhile unless there is a major legacy deployment issue.=A0

Criteria for changes would be Standards Action required. This would also be= cumulative.

To= be in compliance with this specification, applications MUST NOT permit the= use of those algorithms (even if the user requests them).

So to specify compliance, a product would state=A0'Complies with RFC 26= 16, RFC 5246, RFC XXXX & RFC YYYY'

The task of ongoing maintenance would be left to the IETF SAAG and SECDIR. = Actually making these decisions is much less difficult than deciding on hav= ing one place to make them.

Al= though the bar is set at 'standards action required', this would no= rmally be something I would see being done on an individual submission basi= s rather than requiring a Working Group to be formed.

--
Website: http://h= allambaker.com/

--f46d0444ef03bbc20404b1c927ad-- From nico@cryptonector.com Tue Nov 15 10:06:14 2011 Return-Path: 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 DC76421F84A9 for ; Tue, 15 Nov 2011 10:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQUp1ge+Q7GJ for ; Tue, 15 Nov 2011 10:06:10 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id D174621F84A8 for ; Tue, 15 Nov 2011 10:06:10 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 889571DE07D for ; Tue, 15 Nov 2011 10:06:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=vdZd51sGC8N/FeFZyZ79G 6Zj7FOWpTMoJM4PrlOLUl3U9SRr3TYzstCQ9bZZczW9PJYfr1/ytNO/ibmBuuC0c zzdv1MD97znchNI+trc9/A4yXrbVoiRgdItergaqVZoc5i1WOc0EVAhbanXxhyQp GLsiFpDCA2oFdHyJLTUg5w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=GtFhYkCbbJipFIUL63HZ z4zheQs=; b=FSu8grWm6mzNkNasVXSyEGgosmYo/4/JfDDwgZcknx4Qz5xrKdg9 lAg1+j19dbmbhDSFqdKenxGeyKhLMZbd4fH8IMSr3PUa29Mk8dwiwd5A2V4CEuIp WbMAxm1K6pibxZ+ip86JLZFJfG6KL9VJhdiqQn7cIEneT8IxfM+lex4= Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 59BB91DE079 for ; Tue, 15 Nov 2011 10:06:10 -0800 (PST) Received: by yenq4 with SMTP id q4so5252942yen.31 for ; Tue, 15 Nov 2011 10:06:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.12.105 with SMTP id x9mr61443511pbb.109.1321380369286; Tue, 15 Nov 2011 10:06:09 -0800 (PST) Received: by 10.68.192.70 with HTTP; Tue, 15 Nov 2011 10:06:09 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Nov 2011 12:06:09 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 18:06:15 -0000 On Tue, Nov 15, 2011 at 11:16 AM, Phillip Hallam-Baker wrote: > 2) There is no process for maintaining algorithms after a WG has closed. Sure there is! It's whatever process that WG's core documents outline for registration, else the IETF process (individual submissions, find another suitable WG, start a new WG) > 3) Duplication of effort. > What point is served by having the same conversation about which algorithms > to use in 10 different WGs? Modern machines are (mostly) pretty capable and > there are almost no cases where an individual WG need be making protocol > specific choices of algorithm to meet performance or space goals. But different WGs will have different perspectives on certain matters. Should Camellia be specified for TLS, Kerberos, SSH, ...? Should it be mandatory-to-implement? If not, should it be published on the Informational track, or the Standards Track? Answers to these sorts of questions are allowed to vary by WG right now. Perhaps that is a problem, but if not, do we want to lose whatever value we get from being able to answer those questions on a WG-by-WG basis? And if you propose that things like "mandatory-to-implement" be protocol-specific, but all in the same registration entry, should registration be held up until we have consensus for each protocol, or should registrations be updated lazily for each protocol? (I would hope the latter.) Would we have a single list/WG for consensus, or would we still need to do whatever is appropriate for each protocol (e.g., use concluded WG lists)? (I'm not nay-saying here. These are questions to which I see potentially satisfactory answers.) It might make sense to limit this new registry to just a few protocols (PKIX, TLS, CMS, leaving out Kerberos, SSH?), then add the remaining protocols as we gain experience with the new registry. But even so, I think we want some idea of what the registry and registration process will look like when we're done. Also, it'd be nice if we always had an explicit sequence number in all *new* cipher suites, even when a given protocol only requires an octet stream, as TLS and SSH do. DTLS obviously needs this, but it wouldn't hurt SSH, and we really want to never again have modes like chained-IV CBC. This wouldn't be a big change for SSH as it already has this for counter-mode ciphers, basically. It wouldn't be much of a change for GSS-API mechanisms either. But this would be a much more disruptive change for Kerberos. Perhaps the thing to do would be to leave our Kerberos... The one thing we don't want is to make addition of crypto algorithms so difficult that it takes years [more than now] or worse: never happens. This is the biggest scare factor for me regarding your unified registry proposal. > 4) Inconsistency > Using two different crypto algorithms provides the strength of the weakest > one. Inconsistency is almost always worse than a sub-optimal choice. I don't > much care what the RSA signature format used is as long as it is 'good > enough' for me and 'everyone' is using it. The security of the whole is certainly affected by the strength of individual algorithms, but the way in which the whole is put together is critical as well. SHA-1 may suck now, but HMAC-SHA-1 is still considered secure enough. That's one example. The 'whole' consists of key exchange, authentication, KDF/PRF, ciphers, cipher modes, and integrity protection algorithms (except when an AE/AEAD cipher mode takes care of the last), and the way in which these are all combined. > We should make these choices once and have the consequences flow out to all > the protocols that use the algorithms. The 'whole' does vary significantly by protocol because, sadly, the protocols themselves vary so much (or have protocol-specific details that are difficult to abstract). Thus I have a hard time imagining that a shared registry will be enough to allow us to easily analyze and/or ensure the security of our protocols, say. I'm not saying that I don't want a unified theory of crypto protocol, complete with unified algorithm registry. Quite the contrary, I do. I just think there's a lot of work to do to get there. Again, maybe if you start small? Or perhaps start with an informative registry and see if we can eventually get each protocol to switch to it as their normative registry as we gain experience? > 5) 'Vanity' Crypto and other non-Mandatory algorithms. > Cryptography has always been a highly politicized technology. In recent > decades it has been as highly politicized as nuclear power and for much the > same reason: Cryptography was one of the principle technologies that decided > the outcome of WWII and was thus a key technology in the cold war. > The politics behind so-called vanity crypto are very complex and I don't > really want to go into them here. What I wat to do instead is to build a > firewall so that the IETF does not need to get dragged into those politics. Making vanity crypto decisions global to a set of protocols will probably complicate the politics of selecting mandatory-to-implement algorithms. Or perhaps I'm wrong and implementors (and therefore, the IETF) will throw in the towel and accept a large number of mandatory-to-implement algorithms. We probably can't tell without trying. However, though we have lots of deja vu moments today in each protocol/WG, we do benefit from being able to make different MTI decisions in each case (i.e., implementors for each protocol are only affected by consensus for that protocol, not global consensus). > For historical reasons, the IETF preferred algorithms are essentially the > NSA/NIST choices. One approach would be for the IETF to only recognize those > and no others. This is probably not sustainable. Registries such as IANA are > [...] Our preferred algorithms are historical accidents, yes, but ultimately they have to do with consensus and available choices at the time that the choices had to be made. I.e., we have a bit of an accidental first-com-first-served policy, and that implicit policy has been becoming much more of an explicit policy recently (it's convenient that we can interpret the past this way, I know). If we were to have too many algorithms to choose from when we need to choose we'd simply have more interesting discussions -- or are you saying we might then fail to reach consensus? But how would a single registry make it more possible to reach consensus in such a situation?? Nico -- From hallam@gmail.com Tue Nov 15 13:09:08 2011 Return-Path: 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 6CE3F11E8073 for ; Tue, 15 Nov 2011 13:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b52xi4Bvzk5E for ; Tue, 15 Nov 2011 13:09:03 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB2B921F85EF for ; Tue, 15 Nov 2011 13:09:02 -0800 (PST) Received: by faap16 with SMTP id p16so1055462faa.31 for ; Tue, 15 Nov 2011 13:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pdnP/KFNaW4VevhRTlfkhG7qWi+yBop6+b8JJgyLEqQ=; b=LbNMdUNxjTJbDD0cP63AHIi47myYZy4tmGcqtSayO7WeQKL058HM5mjHd0hKfZlszx Ne5wpvXOb0v9DWZtOaLfoGBd3XZF73JxrNyswCe773HT8QZQtT5DkdZvmEnPTcQIXuHj KQo7jENh9kEfvCyUBjHVPZSmKdpi21nSmLRMk= MIME-Version: 1.0 Received: by 10.182.2.225 with SMTP id 1mr6446296obx.30.1321391340646; Tue, 15 Nov 2011 13:09:00 -0800 (PST) Received: by 10.182.42.99 with HTTP; Tue, 15 Nov 2011 13:09:00 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Nov 2011 16:09:00 -0500 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=f46d0444ebad77f20504b1cc6535 Cc: saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 21:09:08 -0000 --f46d0444ebad77f20504b1cc6535 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 15, 2011 at 1:06 PM, Nico Williams wrote: > On Tue, Nov 15, 2011 at 11:16 AM, Phillip Hallam-Baker > wrote: > > > 3) Duplication of effort. > > What point is served by having the same conversation about which > algorithms > > to use in 10 different WGs? Modern machines are (mostly) pretty capable > and > > there are almost no cases where an individual WG need be making protocol > > specific choices of algorithm to meet performance or space goals. > > But different WGs will have different perspectives on certain matters. > Should Camellia be specified for TLS, Kerberos, SSH, ...? Should it > be mandatory-to-implement? If not, should it be published on the > Informational track, or the Standards Track? > I do not think that is actually true. In what circumstances would we want to endorse an algorithm for protocol A knowing that it is not suitable for protocol B? The IETF is in the standards business and one of the things that you do in a standard is you decide what is not part of the standard. I cannot see any argument for any of the following: * Adding Camellia to the mandatory to implement suite for any IETF protocol * Prohibiting use of Camellia for any protocol * In general, adding an algorithm for use with protocol X knowing that it is inappropriate for use in other protocols. There is no shortage of cryptographic algorithms. I can't see why TLS should even spend the time considering Camellia if there was any doubt about the ability to use it in IPSEC. The only algorithms I can ever see being worth consideration at this point would be ones that are sufficiently general purpose that they can be used in multiple protocols. What I am proposing instead is a low bar to making Camellia an option in any IETF protocol. I believe this to be a Pareto improvement as follows: * The developers of Camellia can get their algorithm enabled as an option in all IETF protocols in a single operation. * Parties who might be willing to consider use of Camellia are much more likely to do so if it is an option in all protocols. * WGs do not need to spend time discussing algorithm choice unless they are one of the rare WGs where the problem itself is actually special. IPSEC, CMS, TLS and Jose are all general purpose cryptographic building blocks that are intended for use building other applications. There is really no reason that any of those WGs should ever need to discuss algorithms because it is the applications (e.g. HTTPS, S/MIME) that those arise in. > Answers to these sorts of questions are allowed to vary by WG right > now. Perhaps that is a problem, but if not, do we want to lose > whatever value we get from being able to answer those questions on a > WG-by-WG basis? > I think a WG should be allowed to vary if a case is made to allow that and the AD, IESG etc. accept it. But by default, choice of algorithms should be considered a rat hole. > And if you propose that things like "mandatory-to-implement" be > protocol-specific, but all in the same registration entry, should > registration be held up until we have consensus for each protocol, or > should registrations be updated lazily for each protocol? (I would > hope the latter.) Would we have a single list/WG for consensus, or > would we still need to do whatever is appropriate for each protocol > (e.g., use concluded WG lists)? > No, I see changing mandatory to implement as being something that should happen so infrequently as that this is not an issue. The two drivers for the mandatory to implement set are developments in cryptanalysis/hardware and expiry of IPR claims. We have already done this with the move to AES and the SHA-1 to SHA-2 transition. that required a lot of work because many of the protocols had really not had sufficient thought given to the transition issue. I do not expect to have to go through the same level of effort for the SHA3 transition. Barring some major unexpected cryptanalytic result, the transitions I would anticipate in 'mandatory to implement' over the next decade are : * Define the initial set [RSA, DH, AES, SHA-2, HMAC-SHA2] * Deprecate RSA1024 / Mandate RSA 2048 * Mandate SHA-3 (in parallel with SHA-2) After there is confidence that all remaining EC claims have expired: * Mandate an EC set with a named curve. I don't see that any of those changes would be particularly controversial. we all move in pretty much the same direction anyway. In theory a WG could choose to use something other than AES as its mandatory to implement symmetric encryption algorithm. In practice the only algorithm that there is going to be a consensus for is AES. It might make sense to limit this new registry to just a few protocols > (PKIX, TLS, CMS, leaving out Kerberos, SSH?), then add the remaining > protocols as we gain experience with the new registry. But even so, I > think we want some idea of what the registry and registration process > will look like when we're done. > That would work for me. The key thing though would be to avoid having to discuss this afresh for new WGs that start. > Also, it'd be nice if we always had an explicit sequence number in all > *new* cipher suites, even when a given protocol only requires an octet > stream, as TLS and SSH do. DTLS obviously needs this, but it wouldn't > hurt SSH, and we really want to never again have modes like chained-IV > CBC. This wouldn't be a big change for SSH as it already has this for > counter-mode ciphers, basically. It wouldn't be much of a change for > GSS-API mechanisms either. But this would be a much more disruptive > change for Kerberos. Perhaps the thing to do would be to leave our > Kerberos... > > The one thing we don't want is to make addition of crypto algorithms > so difficult that it takes years [more than now] or worse: never > happens. This is the biggest scare factor for me regarding your > unified registry proposal. The idea was to divide the task into three parts so that the barrier to registration can be made very, very low. I do not want there to be any IETF review of the strength of the algorithms. All that would be required is to state: 1) This document ONLY assigns identifiers, it does not imply any endorsement 2) Specify the code points 3) Specify the test vectors in a predefined format The only 'speed bump' here would be the third part and waiting for the expert review. > 4) Inconsistency > > Using two different crypto algorithms provides the strength of the > weakest > > one. Inconsistency is almost always worse than a sub-optimal choice. I > don't > > much care what the RSA signature format used is as long as it is 'good > > enough' for me and 'everyone' is using it. > > The security of the whole is certainly affected by the strength of > individual algorithms, but the way in which the whole is put together > is critical as well. SHA-1 may suck now, but HMAC-SHA-1 is still > considered secure enough. That's one example. The 'whole' consists > of key exchange, authentication, KDF/PRF, ciphers, cipher modes, and > integrity protection algorithms (except when an AE/AEAD cipher mode > takes care of the last), and the way in which these are all combined. HMAC-SHA-1 is certainly secure for pretty much all known cryptographic purposes. But as I pointed out for MD5, the cost of using HMAC-SHA-1 is now greater than that of using HMAC-SHA-2 because every system that uses SHA-1 in any capacity creates a need for someone like me to periodically (1) determine that SHA1 is sufficient, (2) write up a report explaining that the system is still secure (3) invoice them for the 4-8 hours work resulting. > > We should make these choices once and have the consequences flow out to > all > > the protocols that use the algorithms. > > The 'whole' does vary significantly by protocol because, sadly, the > protocols themselves vary so much (or have protocol-specific details > that are difficult to abstract). Thus I have a hard time imagining > that a shared registry will be enough to allow us to easily analyze > and/or ensure the security of our protocols, say. > Another reason why I only want to analyze the security of the small mandatory-to-implement subset. > Or perhaps start with an informative registry and see if we can > eventually get each protocol to switch to it as their normative > registry as we gain experience? > That would work. > > 5) 'Vanity' Crypto and other non-Mandatory algorithms. > > Cryptography has always been a highly politicized technology. In recent > > decades it has been as highly politicized as nuclear power and for much > the > > same reason: Cryptography was one of the principle technologies that > decided > > the outcome of WWII and was thus a key technology in the cold war. > > The politics behind so-called vanity crypto are very complex and I don't > > really want to go into them here. What I wat to do instead is to build a > > firewall so that the IETF does not need to get dragged into those > politics. > > Making vanity crypto decisions global to a set of protocols will > probably complicate the politics of selecting mandatory-to-implement > algorithms. We cannot stop the Russian federation from passing a law to make GOST mandatory to implement. But nor can they force us to make GOST mandatory to implement. > Or perhaps I'm wrong and implementors (and therefore, the > IETF) will throw in the towel and accept a large number of > mandatory-to-implement algorithms. We probably can't tell without > trying. > The number of mandatory to implement algorithms should usually be one and never more than two. Everyone else just gets their code points assigned and nothing else. Having a choice of algorithms means that you get the security of the weakest one, not the strongest one. The only case in which it is desirable to have two algorithms that are mandatory to implement is when you have one algorithm that is in widespread use that you are looking to phase out in favor of a new one long before that change is forced by an announcement at Crypto or RSA. [OK the SHA-1 / 2/ 3/ change might end up requiring three but that is the type of situation we are looking to avoid in the future] > > Our preferred algorithms are historical accidents, yes, but ultimately > they have to do with consensus and available choices at the time that > the choices had to be made. I.e., we have a bit of an accidental > first-com-first-served policy, and that implicit policy has been > becoming much more of an explicit policy recently (it's convenient > that we can interpret the past this way, I know). If we were to have > too many algorithms to choose from when we need to choose we'd simply > have more interesting discussions -- or are you saying we might then > fail to reach consensus? But how would a single registry make it more > possible to reach consensus in such a situation?? > Consensus would only be required for the Mandatory To Implement (MTI) and Prohibited To Implement (PTI) registries. The unified registry would be almost first come first served. -- Website: http://hallambaker.com/ --f46d0444ebad77f20504b1cc6535 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 15, 2011 at 1:06 PM, Nico Williams <nico@cryptonector.com> wro= te:
On Tue, Nov 15, 2011 at 11:16 AM, Phillip Hallam-Baker &l= t;hallam@gmail.com> wrote:

=A0
> 3) Duplication of effort.
> What point is served by having the same conversation about which algor= ithms
> to use in 10 different WGs? Modern machines are (mostly) pretty capabl= e and
> there are almost no cases where an individual WG need be making protoc= ol
> specific choices of algorithm to meet performance or space goals.

But different WGs will have different perspectives on certain matters= .
=A0Should Camellia be specified for TLS, Kerberos, SSH, ...? =A0Should it be mandatory-to-implement? =A0If not, should it be published on the
Informational track, or the Standards Track?

I do not think that is actually true.=A0

In = what circumstances would we want to endorse an algorithm for protocol A kno= wing that it is not suitable for protocol B?

The IETF is in the standards business and one of the th= ings that you do in a standard is you decide what is not part of the standa= rd. I cannot see any argument for any of the following:

* Adding Camellia to the mandatory to implement suite for any IETF pro= tocol
* Prohibiting use of Camellia for any protocol
* = In general, adding an algorithm for use with protocol X knowing that it is = inappropriate for use in other protocols.

There is no shortage of cryptographic algorithms. I can= 't see why TLS should even spend the time considering Camellia if there= was any doubt about the ability to use it in IPSEC. The only algorithms I = can ever see being worth consideration at this point would be ones that are= sufficiently general purpose that they can be used in multiple protocols.<= /div>

What I am proposing instead is a low bar to making Came= llia an option in any IETF protocol. I believe this to be a Pareto improvem= ent as follows:

* The developers of Camellia can g= et their algorithm enabled as an option in all IETF protocols in a single o= peration.

* Parties who might be willing to consider use of Camel= lia are much more likely to do so if it is an option in all protocols.

* WGs do not need to spend time discussing algorithm c= hoice unless they are one of the rare WGs where the problem itself is actua= lly special.=A0


IPSEC, CMS, TLS and Jose are all general= purpose cryptographic building blocks that are intended for use building o= ther applications. There is really no reason that any of those WGs should e= ver need to discuss algorithms because it is the applications (e.g. HTTPS, = S/MIME) that those arise in.

=A0
Answers to these sorts of questions are allowed to vary by WG right
now. =A0Perhaps that is a problem, but if not, do we want to lose
whatever value we get from being able to answer those questions on a
WG-by-WG basis?

I think a WG should be = allowed to vary if a case is made to allow that=A0and the AD, IESG etc. acc= ept it.

But by default, choice of algorithms shoul= d be considered a rat hole.

=A0
And if you propose that things like "mandatory-to-implement" be protocol-specific, but all in the same registration entry, should
registration be held up until we have consensus for each protocol, or
should registrations be updated lazily for each protocol? =A0(I would
hope the latter.) =A0Would we have a single list/WG for consensus, or
would we still need to do whatever is appropriate for each protocol
(e.g., use concluded WG lists)?

No, I s= ee changing mandatory to implement as being something that should happen so= infrequently as that this is not an issue. The two drivers for the mandato= ry to implement set are developments in cryptanalysis/hardware and expiry o= f IPR claims.=A0

We have already done this with the move to AES and the = SHA-1 to SHA-2 transition. that required a lot of work because many of the = protocols had really not had sufficient thought given to the transition iss= ue. I do not expect to have to go through the same level of effort for the = SHA3 transition.

Barring some major unexpected cryptanalytic result, the= transitions I would anticipate in 'mandatory to implement' over th= e next decade are :=A0

* Define the initial set [R= SA, DH, AES, SHA-2, HMAC-SHA2]

* Deprecate RSA1024 / Mandate RSA 2048=A0
* M= andate SHA-3 (in parallel with SHA-2)

After there = is confidence that all remaining EC claims have expired:

* Mandate an EC set with a named curve.


<= /div>
I don't see that any of those changes would be particularly c= ontroversial. we all move in pretty much the same direction anyway. In theo= ry a WG could choose to use something other than AES as its mandatory to im= plement symmetric encryption algorithm. In practice the only algorithm that= there is going to be a consensus for is AES.

It might make sense to limit= this new registry to just a few protocols
(PKIX, TLS, CMS, leaving out Kerberos, SSH?), then add the remaining
protocols as we gain experience with the new registry. =A0But even so, I think we want some idea of what the registry and registration process
will look like when we're done.

Tha= t would work for me. The key thing though would be to avoid having to discu= ss this afresh for new WGs that start.

=A0
Also, it'd be nice if we always had an explicit sequence number in all<= br> *new* cipher suites, even when a given protocol only requires an octet
stream, as TLS and SSH do. =A0DTLS obviously needs this, but it wouldn'= t
hurt SSH, and we really want to never again have modes like chained-IV
CBC. =A0This wouldn't be a big change for SSH as it already has this fo= r
counter-mode ciphers, basically. =A0It wouldn't be much of a change for=
GSS-API mechanisms either. =A0But this would be a much more disruptive
change for Kerberos. =A0Perhaps the thing to do would be to leave our
Kerberos...

The one thing we don't want is to make addition of crypto algorithms so difficult that it takes years [more than now] or worse: never
happens. =A0This is the biggest scare factor for me regarding your
unified registry proposal.

The idea was to = divide the task into three parts so that the barrier to registration can be= made very, very low.

I do not want there to be an= y IETF review of the strength of the algorithms. All that would be required= is to state:

1) This document ONLY assigns identifiers, it does not = imply any endorsement
2) Specify the code points
3) Spe= cify the test vectors in a predefined format

The o= nly 'speed bump' here would be the third part and waiting for the e= xpert review.

> 4) Inconsistency
> Using two different crypto algorithms provides the strength of the wea= kest
> one. Inconsistency is almost always worse than a sub-optimal choice. I= don't
> much care what the RSA signature format used is as long as it is '= good
> enough' for me and 'everyone' is using it.

The security of the whole is certainly affected by the strength of individual algorithms, but the way in which the whole is put together
is critical as well. =A0SHA-1 may suck now, but HMAC-SHA-1 is still
considered secure enough. =A0That's one example. =A0The 'whole'= consists
of key exchange, authentication, KDF/PRF, ciphers, cipher modes, and
integrity protection algorithms (except when an AE/AEAD cipher mode
takes care of the last), and the way in which these are all combined.

HMAC-SHA-1 is certainly secure for pretty much a= ll known cryptographic purposes. But as I pointed out for MD5, the cost of = using HMAC-SHA-1 is now greater than that of using HMAC-SHA-2 because every= system that uses SHA-1 in any capacity creates a need for someone like me = to periodically (1) determine that SHA1 is sufficient, (2) write up a repor= t explaining that the system is still secure (3) invoice them for the 4-8 h= ours work resulting.

=A0
> We should make these choices once and have the consequences flow out t= o all
> the protocols that use the algorithms.

The 'whole' does vary significantly by protocol because, sadl= y, the
protocols themselves vary so much (or have protocol-specific details
that are difficult to abstract). =A0Thus I have a hard time imagining
that a shared registry will be enough to allow us to easily analyze
and/or ensure the security of our protocols, say.

=
Another reason why I only want to analyze the security of the sm= all mandatory-to-implement subset.
=A0
Or perhaps start with an informative registry and see if we can
eventually get each protocol to switch to it as their normative
registry as we gain experience?

That wo= uld work.=A0


> 5) 'Vanity' Crypto and other non-Mandatory algorithms.
> Cryptography has always been a highly politicized technology. In recen= t
> decades it has been as highly politicized as nuclear power and for muc= h the
> same reason: Cryptography was one of the principle technologies that d= ecided
> the outcome of WWII and was thus a key technology in the cold war.
> The politics behind so-called vanity crypto are very complex and I don= 't
> really want to go into them here. What I wat to do instead is to build= a
> firewall so that the IETF does not need to get dragged into those poli= tics.

Making vanity crypto decisions global to a set of protocols will
probably complicate the politics of selecting mandatory-to-implement
algorithms. =A0

We cannot stop the Russian = federation from passing a law to make GOST mandatory to implement. But nor = can they force us to make GOST mandatory to implement.
=A0
Or perhaps I'm wrong and implementors (= and therefore, the
IETF) will throw in the towel and accept a large number of
mandatory-to-implement algorithms. =A0We probably can't tell without trying.

The number of mandatory to impl= ement algorithms should usually be one and never more than two. Everyone el= se just gets their code points assigned and nothing else.

Having a choice of algorithms means that you get the security of= the weakest one, not the strongest one. The only case in which it is desir= able to have two algorithms that are mandatory to implement is when you hav= e one algorithm that is in widespread use that you are looking to phase out= in favor of a new one long before that change is forced by an announcement= at Crypto or RSA.

[OK the SHA-1 / 2/ 3/ change might end up requiring thr= ee but that is the type of situation we are looking to avoid in the future]=
=A0

Our preferred algorithms are historical accidents, yes, but ultimately
they have to do with consensus and available choices at the time that
the choices had to be made. =A0I.e., we have a bit of an accidental
first-com-first-served policy, and that implicit policy has been
becoming much more of an explicit policy recently (it's convenient
that we can interpret the past this way, I know). =A0If we were to have
too many algorithms to choose from when we need to choose we'd simply have more interesting discussions -- or are you saying we might then
fail to reach consensus? =A0But how would a single registry make it more possible to reach consensus in such a situation??

Consensus would only be required for the Mandatory To Implement (MTI) an= d Prohibited To Implement (PTI) registries. The unified registry would be a= lmost first come first served.


--
Website: http://hallambaker.com/

--f46d0444ebad77f20504b1cc6535-- From jhutz@cmu.edu Tue Nov 15 14:16:30 2011 Return-Path: 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 56AB011E80B0 for ; Tue, 15 Nov 2011 14:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHBWoIBH6TZy for ; Tue, 15 Nov 2011 14:16:29 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 85BE311E80AB for ; Tue, 15 Nov 2011 14:16:29 -0800 (PST) Received: from [128.2.216.42] (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id pAFMGNso011900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Nov 2011 17:16:24 -0500 (EST) From: Jeffrey Hutzelman To: Phillip Hallam-Baker In-Reply-To: <1416_1321391352_pAFL9AGV023452_CAMm+LwioQiF167ewRJAZoeB180MSH6SPkyWcG1XgKNJ0wsj+NQ@mail.gmail.com> References: <1416_1321391352_pAFL9AGV023452_CAMm+LwioQiF167ewRJAZoeB180MSH6SPkyWcG1XgKNJ0wsj+NQ@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 15 Nov 2011 17:16:23 -0500 Message-ID: <1321395383.5944.41.camel@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: saag@ietf.org, jhutz@cmu.edu Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 22:16:30 -0000 On Tue, 2011-11-15 at 16:09 -0500, Phillip Hallam-Baker wrote: > In what circumstances would we want to endorse an algorithm for > protocol A knowing that it is not suitable for protocol B? Easy: when protocol A and protocol B have different requirements. > What I am proposing instead is a low bar to making Camellia an option > in any IETF protocol. I believe this to be a Pareto improvement as > follows: > > > * The developers of Camellia can get their algorithm enabled as an > option in all IETF protocols in a single operation. No, it's not that easy. "Use Camellia" is not a protocol specification, and cipher suite specifications for TLS and CMS are so vague that frankly I'm surprised there is any interoperability at all. In the rest of the IETF, there is per-protocol technical specification work that needs to be done in order to use a new algorithm. > I think a WG should be allowed to vary if a case is made to allow > that and the AD, IESG etc. accept it. Ah, so you are proposing to change process. Right now, those decisions are primarily up to each WG; you are proposing that we instead require someone to "approve" some sort of "exception" before a WG is allowed to make such decisions for itself. That's not necessarily bad, but it is a change. > > But by default, choice of algorithms should be considered a rat hole. > > > > And if you propose that things like "mandatory-to-implement" > be > protocol-specific, but all in the same registration entry, > should > registration be held up until we have consensus for each > protocol, or > should registrations be updated lazily for each protocol? (I > would > hope the latter.) Would we have a single list/WG for > consensus, or > would we still need to do whatever is appropriate for each > protocol > (e.g., use concluded WG lists)? > No, I see changing mandatory to implement as being something that > should happen so infrequently as that this is not an issue. The two > drivers for the mandatory to implement set are developments in > cryptanalysis/hardware and expiry of IPR claims. And changes in requirements, and implementation considerations, and performance considerations, and defending against _future_ changes in any of those. > The number of mandatory to implement algorithms should usually be one People keep saying that, but in fact I think that's a horrible idea. If you only have one MTI algorithm, then when that algorithm is suddenly, spectacularly broken, everyone is screwed. You can't just declare some new algorithm MTI, because that _doesn't solve the problem_. What solves the problem is _deploying_ the new algorithm, and having to wait three years for the IETF to choose a new MTI algorithm and then for vendors to implement, test, and ship it just doesn't cut it. In most cases we should have _at least two_ MTI algorithms whenever possible, so that if one is broken we (operators) can simply turn it off and everything continues to work. That said... > and never more than two. Everyone else just gets their code points > assigned and nothing else. ... I mostly agree with this point, modulo the observation that for some protocols, some protocol-specific technical specification work is required. For such protocols, code points should not be assigned until the needed specification is available. Of course, this is in most cases separate from the question of the extent to which the algorithm itself is documented. > Consensus would only be required for the Mandatory To Implement (MTI) > and Prohibited To Implement (PTI) registries. The unified registry > would be almost first come first served. A "Prohibited to Implement" registry makes no sense; people would simply choose not to comply. And really, what customer is going to demand that a vendor comply with a standard whose sole purpose is to restrict the choices available to the customer? Besides, it wouldn't help, because _existing_ versions of products wouldn't magically lose capabilities just because something was added to such a registry. What you really want is a registry of algorithms that the IETF recommends no longer be _deployed_. -- Jeff From nico@cryptonector.com Tue Nov 15 14:58:18 2011 Return-Path: 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 B43B71F0C7B for ; Tue, 15 Nov 2011 14:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxfQ7jEhqgNF for ; Tue, 15 Nov 2011 14:58:14 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id AA88A1F0C34 for ; Tue, 15 Nov 2011 14:58:14 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 4E22C1F0081 for ; Tue, 15 Nov 2011 14:58:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Ni3fBeM6Z+Chv2p4fOvCBiPHzTN1N5Gbg0C0qd32aMvt 9B6y4xZDgSqy71Pbjx40ZpYumpnJdLE22mC+Z4gRcGAtAfBCGuiHYqm6Elpblf4c tBt1ayqzyEjfe4sXLf8FcfRjlKjPv+LL+KOSCWis1V621KWJNYU3C4+9QFOdh3g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=okIe0qBnS5bVz9CFZrm8xIUyTC8=; b=Mo1GQsIhMHL qn1yBgQCMgCQTDQSdjz2wY5xq5lVvz9XnariJ1HPYX5mbCT3gSr+aEu4/cY/tgNM B6J+qYHiLViQMYTbxOfl0DBCOQQBNt/eKWYSJhtUGpRTzstp7v4/DdZIDQTiubCi psvfAMfK40k4ZSa0DZ0FH5ZFVruiJj04= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 141E71F0078 for ; Tue, 15 Nov 2011 14:58:14 -0800 (PST) Received: by vws5 with SMTP id 5so8185345vws.31 for ; Tue, 15 Nov 2011 14:58:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.97.35 with SMTP id dx3mr46067941vdb.2.1321397893329; Tue, 15 Nov 2011 14:58:13 -0800 (PST) Received: by 10.220.98.6 with HTTP; Tue, 15 Nov 2011 14:58:13 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Nov 2011 16:58:13 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 22:58:18 -0000 On Tue, Nov 15, 2011 at 3:09 PM, Phillip Hallam-Baker wr= ote: > On Tue, Nov 15, 2011 at 1:06 PM, Nico Williams > wrote: >> On Tue, Nov 15, 2011 at 11:16 AM, Phillip Hallam-Baker >> wrote: >> But different WGs will have different perspectives on certain matters. >> =C2=A0Should Camellia be specified for TLS, Kerberos, SSH, ...? =C2=A0Sh= ould it >> be mandatory-to-implement? =C2=A0If not, should it be published on the >> Informational track, or the Standards Track? > > I do not think that is actually true. > In what circumstances would we want to endorse an algorithm for protocol = A > knowing that it is not suitable for protocol B? We currently let each WG decide on its own. > The IETF is in the standards business and one of the things that you do i= n a > standard is you decide what is not part of the standard. I cannot see any > argument for any of the following: > * Adding Camellia to the mandatory to implement suite for any IETF protoc= ol > * Prohibiting use of Camellia for any protocol > * In general, adding an algorithm for use with protocol X knowing that it= is > inappropriate for use in other protocols. We certainly do the last w.r.t. cipher *modes*. For example, counter modes are not appropriate for use in Kerberos PDUs other than KRB-PRIV, KRB-SAFE, and KRB-CRED, but that doesn't stop us using counter modes elsewhere. As to whether Camellia (for example) can ever get made MTI for any IETF protocols, I can certainly imagine situations that might lead us to doing so (e.g., serious cryptanalytic advances against AES). In the meantime, I agree, but we're still letting each WG decide this on its own. > What I am proposing instead is a low bar to making Camellia an option in = any > IETF protocol. I believe this to be a Pareto improvement as follows: > * The developers of Camellia can get their algorithm enabled as an option= in > all IETF protocols in a single operation. > * Parties who might be willing to consider use of Camellia are much more > likely to do so if it is an option in all protocols. > * WGs do not need to spend time discussing algorithm choice unless they a= re > one of the rare WGs where the problem itself is actually special. The last item is likely unavoidable for any protocol where a given cipher or cipher mode presents any challenges. Camellia is NOT such a cipher for any Internet protocol that I can think of, so it's not a good example. > I think a WG should be allowed to vary if a case is made to allow that=C2= =A0and > the AD, IESG etc. accept it. > But by default, choice of algorithms should be considered a rat hole. I agree, but it is easier, politically, for the IETF and IESG to let WGs have more freedom. .. > No, I see changing mandatory to implement as being something that should > happen so infrequently as that this is not an issue. The two drivers for = the > mandatory to implement set are developments in cryptanalysis/hardware and > expiry of IPR claims. I agree, though I'd add significant performance improvements as another potential driver (particularly for hash functions and ECC curves). > Barring some major unexpected cryptanalytic result, the transitions I wou= ld > anticipate in 'mandatory to implement' over the next decade are : > * Define the initial set [RSA, DH, AES, SHA-2, HMAC-SHA2] > * Deprecate RSA1024 / Mandate RSA 2048 > * Mandate SHA-3 (in parallel with SHA-2) > After there is confidence that all remaining EC claims have expired: > * Mandate an EC set with a named curve. Yes. >> It might make sense to limit this new registry to just a few protocols >> (PKIX, TLS, CMS, leaving out Kerberos, SSH?), then add the remaining >> protocols as we gain experience with the new registry. =C2=A0But even so= , I >> think we want some idea of what the registry and registration process >> will look like when we're done. > > That would work for me. The key thing though would be to avoid having to > discuss this afresh for new WGs that start. OK. The more we can fit in this initially the better, provided we don't make it too hard to make progress. I'm still not sure what the right set of initial protocols for the new registry would be. >> The one thing we don't want is to make addition of crypto algorithms >> so difficult that it takes years [more than now] or worse: never >> happens. =C2=A0This is the biggest scare factor for me regarding your >> unified registry proposal. > > The idea was to divide the task into three parts so that the barrier to > registration can be made very, very low. > I do not want there to be any IETF review of the strength of the algorith= ms. > All that would be required is to state: My concern is about the time to get the new registry off the ground. >> The 'whole' does vary significantly by protocol because, sadly, the >> protocols themselves vary so much (or have protocol-specific details >> that are difficult to abstract). =C2=A0Thus I have a hard time imagining >> that a shared registry will be enough to allow us to easily analyze >> and/or ensure the security of our protocols, say. > > Another reason why I only want to analyze the security of the small > mandatory-to-implement subset. The problem is not the size of the MTI set, but the size of the protocol set for which we're doing this. >> Or perhaps start with an informative registry and see if we can >> eventually get each protocol to switch to it as their normative >> registry as we gain experience? > > That would work. OK. Something to keep in mind if we have trouble obtaining consensus for a normative registry. > We cannot stop the Russian federation from passing a law to make GOST > mandatory to implement. But nor can they force us to make GOST mandatory = to > implement. The sooner every government gets this, the better. So, for me the main thing left is the schema for the registry entries, so to speak, given the need to cover disparate protocols. There's a fair bit of detail to get into a registry entry, enough that an RFC seems better for every detail other than the code point allocations. Nico -- From mcgrew@cisco.com Tue Nov 15 15:29:21 2011 Return-Path: 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 170CC11E8101 for ; Tue, 15 Nov 2011 15:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.391 X-Spam-Level: X-Spam-Status: No, score=-106.391 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVdc5Wcp7b3X for ; Tue, 15 Nov 2011 15:29:19 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDB811E80D4 for ; Tue, 15 Nov 2011 15:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=34118; q=dns/txt; s=iport; t=1321399759; x=1322609359; h=cc:message-id:from:to:in-reply-to:mime-version:subject: date:references; bh=1NXfMEWl7dIuU5s4KUfyxIXVnp9/KAB2Z8jD1yxZgdc=; b=Xiz8t894pudXS4wJyLx/Evv+iL873W4u6RYg/vN6RQrmBub/l6BgDLSV gXZ9pSPhuOsb0rvN15NwiaPfYqPLO4SdadxqePAKwFQGgQYvhJarz0KOM TUhgK4KT8pXa9SjFO1lGDbD39/kTifIHknxLsADC1jp5UVTl/0eIJGqvZ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8GAOf0wk6rRDoI/2dsb2JhbABDgk2XX4dSAYdygQWBcgEBAQMBAQEBDwEHUQMLBQsLOA4nMAYTCRmHYAiaPAGeTokuYwSIE4wfhTuMYA X-IronPort-AV: E=Sophos;i="4.69,517,1315180800"; d="scan'208,217";a="14501669" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 15 Nov 2011 23:29:18 +0000 Received: from [10.32.254.210] ([10.32.254.210]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAFNTGrQ024665; Tue, 15 Nov 2011 23:29:17 GMT Message-Id: <7EB95733-E3E1-4876-B977-E6B696433B6B@cisco.com> From: David McGrew To: Phillip Hallam-Baker In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-907--504827465 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 15 Nov 2011 15:29:16 -0800 References: X-Mailer: Apple Mail (2.936) Cc: saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 23:29:21 -0000 --Apple-Mail-907--504827465 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Philip, On Nov 15, 2011, at 9:16 AM, Phillip Hallam-Baker wrote: > This issue keeps coming up. I think that events are converging in a > way that forces us to finally do something. > > At present the IETF has some tens of protocols that use > cryptographic algorithms. Some use one registry, others use another, > some use no registry at all, some use OIDs and so on. that's absolutely right, but it is worth mentioning that there is an IETF registry for crypto algorithms that is used across several different protocols: the Authenticated Encryption registry defined in RFC 5116 that is used in TLS 1.2 (RFC 5246), IKEv2 (RFC 5282), SSH (RFC 5647), SRTP (draft-ietf-avt-srtp-aes-gcm-02), and JSMS (draft-rescorla- jsms-00). (ESP is compatible, but not formally specified, as is IEEE MACsec for that matter.) > I see the following problems with the current situation: > > > 1) There is no established process for telling people 'do not use > 512 bit RSA keys with any IETF protocol.' > > We have recently had some issues arising from use of 512 bit > certificates. This is a problem that should never have occurred. > Browser vendors and CAs have both known of the security issues > relating to 512 bits for a decade. But we still managed to end up > with breaches occurring because everyone was waiting for someone > else to take action. > > Some party needs to take action here and say that they are going to > decide when to tell people to stop using obsolete crypto. The actual > advice given being much less important than the decision to take > responsibility for giving it. > > Remember that using stronger cryptographic algorithms DOES NOT make > you any more secure. The only way to make yourself more secure is to > STOP USING the insecure ones. Phasing out MD4 and MD5 is much more > important than deploying support for the SHA-2 replacement. Standards action setting minimal key sizes would be good. I'm not sure that we need a registry to do that, though; we could use an approach like RFC 6150. But a registry could help. > > > 2) There is no process for maintaining algorithms after a WG has > closed. > > At one point quite a few Security Area groups appeared to be kept > going more or less for the sole purpose of twiddling crypto > algorithms. At the moment the IETF has a process for setting minimum > key lengths for PKIX certs. But when PKIX closes the only mechanism > will be a personal submission to change a standard developed by the > WG for over 15 years. That seems to be a mismatch to me. > > Agreed. > 3) Duplication of effort. > > What point is served by having the same conversation about which > algorithms to use in 10 different WGs? Modern machines are (mostly) > pretty capable and there are almost no cases where an individual WG > need be making protocol specific choices of algorithm to meet > performance or space goals. > > Back in 1995 we had to consider performance quite closely. 512 bit > certs actually made some sense at that point. We did not have AES. > We were dealing with the FBI and part of the NSA trying to prevent > use of strong crypto. Choice of algorithm was a much harder choice > then and often had to be fitted to the specific protocol. > > Today there are still circumstances where performance constraints > are significant. For example, the low performance devices I work > with in my control systems work. But that means a choice between > public key and symmetric key rather than between standards based > crypto and some purpose built homebrew scheme. For most low > performance devices, AES is now the algorithm preferred over all > others because it is available in hardware. > > We are going to have to have a conversation about which algorithms > we are going to choose somewhere. At the moment we face the choice > of either have that conversation in Jose and then have it again in > the next WG or have the discussion at a Security Area level and re- > use those choices in the future. Agreed. > > > 4) Inconsistency > > Using two different crypto algorithms provides the strength of the > weakest one. Inconsistency is almost always worse than a sub-optimal > choice. I don't much care what the RSA signature format used is as > long as it is 'good enough' for me and 'everyone' is using it. > > We should make these choices once and have the consequences flow out > to all the protocols that use the algorithms. > > There have been a few prior attempts to deploy a registry that would > cover more than one protocol. But to date there has been no registry > that has really done what is needed to unify all the registries into > one place and establish a unified process for change control. > > I'm not sure I completely understand this point. > 5) 'Vanity' Crypto and other non-Mandatory algorithms. > > Cryptography has always been a highly politicized technology. In > recent decades it has been as highly politicized as nuclear power > and for much the same reason: Cryptography was one of the principle > technologies that decided the outcome of WWII and was thus a key > technology in the cold war. > > The politics behind so-called vanity crypto are very complex and I > don't really want to go into them here. What I wat to do instead is > to build a firewall so that the IETF does not need to get dragged > into those politics. > > For historical reasons, the IETF preferred algorithms are > essentially the NSA/NIST choices. One approach would be for the IETF > to only recognize those and no others. This is probably not > sustainable. Registries such as IANA are only stable so long as they > are willing to register code points on a basis that is acceptable to > the parties that need code points to be defined. If IETF/IANA > refuses to assign code points then the refused parties will simply > pick a code point and use it. This has occurred repeatedly in other > venues. That is why there is a hole blocked out in the MAC address > space, the storage providers wanted a globally unique address and > saw no reason to pay IEEE for the numbers. That is why barcodes are > structured as they are. > > Another approach is simply first come first served. I do not like > that approach as it means that the IETF ends up 'endorsing' the use > of broken crypto. But it is arguably better for the IETF to have a > policy that allows for anyone to register in a way that ensures that > a disclaimer is applied than to try to weed out the bad ones and not > do a good job of it. > > One caveat that comes up is that some protocols have limited space > for code points. But this can almost certainly be dealt with by some > form of extension mechanism that allows use of a common code space > (e.g. OIDs) for non mandatory to implement algorithms. > > > > Thus my proposal (which I will write up as an ID if people like the > approach). > > IETF requests IANA create three new registries of cryptographic > algorithms as follows: > > > 1) Registry of Cryptographic Algorithm Identifiers. > > This would be a registry that is divided up into separate sub- > registries for various types of algorithm (public key signature, > public key encryption, digest, encryption, mac, suites, etc.) > > The criteria for inclusion would be expert review and RFC required. > > The RFC would start off with a pre-amble that states that the IETF > makes no endorsement of the strength of the cryptographic algorithm > and the expert review would be strictly limited to determining that > the format of the document is correct, the document would not be > allowed to specify code either. The purpose of these requirements > being to prevent people from presenting assignment of code points as > an IETF endorsement of the algorithm strength. > > The document would be required to: > > 1) Specify the code points for ASN.1 OID, text string, URI and > optionally additional code points for IPSEC, DNSSEC, etc. > 2) Specify test vectors in a format that ensures that endian-ness > issues are addressed. > 3) Specify the location where further documentation is to be found > (which might be another RFC). > The AEAD registry essentially meets these requirements (for symmetric authenticated encryption). This is a good thing, both because it is proof that the goal is achievable, and because AEAD is exactly what the IETF should be promoting for symmetric encryption. > > 2) Registry of Mandatory to Implement Algorithms > > This would be a subset of the algorithms specified in the first > registry and would normally consist of exactly one algorithm of each > class. > > Criteria for changes would be Standards Action required. Each RFC > making changes would specify the full list of required algorithms > each time. > > Specifying compliance with this would be separate from specifying > compliance with the base specification. So if a vendor was > specifying standards compliance for its Web server it would specify > 'Complies with RFC 2616, RFC 5246 & RFC XXXX' > > > 3) Registry of Deprecated Algorithms. > > This is the registry of algorithms and key sizes that IETF warns > against using. The warning may be immediate or have some specific > action date. > > It would also be possible to state that an algorithm is deprecated > for specific purposes or with certain protocols. For example, MD5 > should not be used for any purpose that requires protection against > collision attack. There are certainly cases where use of MD5 does > not raise a security issue, though the cost of going through the > necessary justification is almost never going to be worthwhile > unless there is a major legacy deployment issue. > > Criteria for changes would be Standards Action required. This would > also be cumulative. > > To be in compliance with this specification, applications MUST NOT > permit the use of those algorithms (even if the user requests them). > > So to specify compliance, a product would state 'Complies with RFC > 2616, RFC 5246, RFC XXXX & RFC YYYY' > > > The task of ongoing maintenance would be left to the IETF SAAG and > SECDIR. Actually making these decisions is much less difficult than > deciding on having one place to make them. > > Although the bar is set at 'standards action required', this would > normally be something I would see being done on an individual > submission basis rather than requiring a Working Group to be formed. > This is an interesting approach. It is ambitious to use registries, rather than relying on an RFC that defines the MUST implement algorithms. If I understand right, your aim is to define a single must-implement algorithm, a set of must-not-implement deprecated algorithms, and then to allow WGs to choose to mandate or recommend other algorithms? Is that the intent? There is complexity in the algorithm details that isn't dealt with in this proposal (at least not explicitly dealt with). For symmetric crypto, there are issues of block cipher modes of operation (e.g. CBC and GCM) and IV generation, and authentication (CBC needs a separate authentication algorithm). Different protocols handle the ordering of authentication and encryption differently, and handle IV generation differently. Now, for symmetric crypto, these issues mostly go away if we go with AEAD. But no protocol yet has made an AEAD algorithm mandatory to implement, so this would be a significant move for WGs. I have not looked into the details for asymmetric crypto, but I would expect similar complexity there. I think this is worth investigating, though. In any consideration of crypto algorithms, IRTF crypto forurm RG should provide input on security, performance, and other technical issues, and should be consulted. Which I'm sure the Security ADs would do, but I'm mentioning it so that others don't forget about the resource ;-) David > -- > Website: http://hallambaker.com/ > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail-907--504827465 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Philip,

On = Nov 15, 2011, at 9:16 AM, Phillip Hallam-Baker wrote:

This = issue keeps coming up. I think that events are converging in a way that = forces us to finally do something.

At present = the IETF has some tens of protocols that use cryptographic algorithms. = Some use one registry, others use another, some use no registry at all, = some use OIDs and so on.

that's = absolutely right, but it is worth mentioning that there is an IETF = registry for crypto algorithms that is used across several different = protocols: the Authenticated Encryption registry defined in RFC = 5116 <http://www.iana.org/assignments/aead-parameters/aead-parameters.xml= > that is used in TLS 1.2 (RFC 5246), IKEv2 (RFC 5282), SSH (RFC = 5647), SRTP (draft-ietf-avt-srtp-aes-gcm-02), and JSMS = (draft-rescorla-jsms-00).   (ESP is compatible, but not formally = specified, as is IEEE MACsec for that matter.) =  


I see the = following problems with the current situation:
=


1) There is no established process = for telling people 'do not use 512 bit RSA keys with any IETF = protocol.'

We have recently had some issues = arising from use of 512 bit certificates. This is a problem that should = never have occurred. Browser vendors and CAs have both known of the = security issues relating to 512 bits for a decade. But we still managed = to end up with breaches occurring because everyone was waiting for = someone else to take action.

Some party needs = to take action here and say that they are going to decide when to tell = people to stop using obsolete crypto. The actual advice given being much = less important than the decision to take responsibility for giving = it.

Remember that using stronger cryptographic = algorithms DOES NOT make you any more secure. The only way to make = yourself more secure is to STOP USING the insecure ones. Phasing out MD4 = and MD5 is much more important than deploying support for the SHA-2 = replacement.

Standards action = setting minimal key sizes would be good.  I'm not sure that we need = a registry to do that, though; we could use an approach like = RFC 6150.  But a registry could help.



2) There is no process = for maintaining algorithms after a WG has = closed.

At one point quite a few Security Area = groups appeared to be kept going more or less for the sole purpose of = twiddling crypto algorithms. At the moment the IETF has a process for = setting minimum key lengths for PKIX certs. But when PKIX closes the = only mechanism will be a personal submission to change a standard = developed by the WG for over 15 years. That seems to be a mismatch to = me.
=



Agreed.
3) Duplication of = effort.

What point is served by having the same = conversation about which algorithms to use in 10 different WGs? Modern = machines are (mostly) pretty capable and there are almost no cases where = an individual WG need be making protocol specific choices of algorithm = to meet performance or space goals.

Back in = 1995 we had to consider performance quite closely. 512 bit certs = actually made some sense at that point. We did not have AES. We were = dealing with the FBI and part of the NSA trying to prevent use of strong = crypto. Choice of algorithm was a much harder choice then and often had = to be fitted to the specific protocol.

Today = there are still circumstances where performance constraints are = significant. For example, the low performance devices I work with in my = control systems work. But that means a choice between public key and = symmetric key rather than between standards based crypto and some = purpose built homebrew scheme. For most low performance devices, AES is = now the algorithm preferred over all others because it is available in = hardware.

We are going to have to have a = conversation about which algorithms we are going to choose somewhere. At = the moment we face the choice of either have that conversation in Jose = and then have it again in the next WG or have the discussion at a = Security Area level and re-use those choices in the = future.


Agreed.
=


4) = Inconsistency

Using two different crypto = algorithms provides the strength of the weakest one. Inconsistency is = almost always worse than a sub-optimal choice. I don't much care what = the RSA signature format used is as long as it is 'good enough' for me = and 'everyone' is using it.

We should make = these choices once and have the consequences flow out to all the = protocols that use the algorithms.

There have = been a few prior attempts to deploy a registry that would cover more = than one protocol. But to date there has been no registry that has = really done what is needed to unify all the registries into one place = and establish a unified process for change control.
=



I'm not = sure I completely understand this point.  

5) 'Vanity' Crypto and other non-Mandatory = algorithms.

Cryptography has always been a = highly politicized technology. In recent decades it has been as highly = politicized as nuclear power and for much the same reason: Cryptography = was one of the principle technologies that decided the outcome of WWII = and was thus a key technology in the cold war.
=

The politics behind so-called vanity crypto are very = complex and I don't really want to go into them here. What I wat to do = instead is to build a firewall so that the IETF does not need to get = dragged into those politics.

For historical = reasons, the IETF preferred algorithms are essentially the NSA/NIST = choices. One approach would be for the IETF to only recognize those and = no others. This is probably not sustainable. Registries such as IANA are = only stable so long as they are willing to register code points on a = basis that is acceptable to the parties that need code points to be = defined. If IETF/IANA refuses to assign code points then the refused = parties will simply pick a code point and use it. This has occurred = repeatedly in other venues. That is why there is a hole blocked out in = the MAC address space, the storage providers wanted a globally unique = address and saw no reason to pay IEEE for the numbers. That is why = barcodes are structured as they are.

Another = approach is simply first come first served. I do not like that approach = as it means that the IETF ends up 'endorsing' the use of broken crypto. = But it is arguably better for the IETF to have a policy that allows for = anyone to register in a way that ensures that a disclaimer is applied = than to try to weed out the bad ones and not do a good job of it.
=

One caveat that comes up is that some protocols have = limited space for code points. But this can almost certainly be dealt = with by some form of extension mechanism that allows use of a common = code space (e.g. OIDs) for non mandatory to implement algorithms.
=



Thus my proposal = (which I will write up as an ID if people like the approach).
IETF requests IANA create three new registries of = cryptographic algorithms as follows:

1) Registry of Cryptographic Algorithm = Identifiers.

This = would be a registry that is divided up into separate sub-registries for = various types of algorithm (public key signature, public key encryption, = digest, encryption, mac, suites, etc.)

The = criteria for inclusion would be expert review and RFC = required. 

The = RFC would start off with a pre-amble that states that the IETF makes no = endorsement of the strength of the cryptographic algorithm and the = expert review would be strictly limited to determining that the format = of the document is correct, the document would not be allowed to specify = code either. The purpose of these requirements being to prevent people = from presenting assignment of code points as an IETF endorsement of the = algorithm strength.

The document would = be required to:

1) Specify the code points for ASN.1 = OID, text string, URI and optionally additional code points for IPSEC, = DNSSEC, etc.
2) Specify test vectors in a format that ensures that = endian-ness issues are addressed.
3) Specify the location where further = documentation is to be found (which might be another RFC).
=

The AEAD registry essentially = meets these requirements (for symmetric authenticated encryption). =   This is a good thing, both because it is proof that the goal is = achievable, and because AEAD is exactly what the IETF should be = promoting for symmetric encryption.  


2) Registry of Mandatory to Implement = Algorithms

This would be a subset of the = algorithms specified in the first registry and would normally consist of = exactly one algorithm of each class. 


= Specifying compliance with this would be separate from specifying = compliance with the base specification. So if a vendor was specifying = standards compliance for its Web server it would specify 'Complies with = RFC 2616, RFC 5246 & RFC XXXX'

=
3) Registry of Deprecated Algorithms.
=
This is the registry of algorithms and key sizes that IETF = warns against using. The warning may be immediate or have some specific = action date.

It = would also be possible to state that an algorithm is deprecated for = specific purposes or with certain protocols. For example, MD5 should not = be used for any purpose that requires protection against collision = attack. There are certainly cases where use of MD5 does not raise a = security issue, though the cost of going through the necessary = justification is almost never going to be worthwhile unless there is a = major legacy deployment issue. 

= Criteria for changes would be Standards Action required. This would also = be cumulative.

To be in compliance with this = specification, applications MUST NOT permit the use of those algorithms = (even if the user requests them).

So to specify = compliance, a product would state 'Complies with RFC 2616, RFC = 5246, RFC XXXX & RFC YYYY'


The task of ongoing maintenance = would be left to the IETF SAAG and SECDIR. Actually making these = decisions is much less difficult than deciding on having one place to = make them.

-- =
Website: http://hallambaker.com/

= _______________________________________________
saag mailing = list
saag@ietf.org
https://www.ietf.org/m= ailman/listinfo/saag

= --Apple-Mail-907--504827465-- From jhutz@cmu.edu Tue Nov 15 15:45:14 2011 Return-Path: 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 CDEE411E8132 for ; Tue, 15 Nov 2011 15:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQ8Xt4uiYDH9 for ; Tue, 15 Nov 2011 15:45:14 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id 1513211E8131 for ; Tue, 15 Nov 2011 15:45:14 -0800 (PST) Received: from [128.2.216.42] (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id pAFNj9C0020248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Nov 2011 18:45:09 -0500 (EST) From: Jeffrey Hutzelman To: David McGrew In-Reply-To: <25866_1321399763_pAFNTMaK001839_7EB95733-E3E1-4876-B977-E6B696433B6B@cisco.com> References: <25866_1321399763_pAFNTMaK001839_7EB95733-E3E1-4876-B977-E6B696433B6B@cisco.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 15 Nov 2011 18:45:09 -0500 Message-ID: <1321400709.5944.48.camel@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: Phillip Hallam-Baker , saag@ietf.org, jhutz@cmu.edu Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 23:45:14 -0000 On Tue, 2011-11-15 at 15:29 -0800, David McGrew wrote: > Hi Philip, > > On Nov 15, 2011, at 9:16 AM, Phillip Hallam-Baker wrote: > > > This issue keeps coming up. I think that events are converging in a > > way that forces us to finally do something. > > > > > > At present the IETF has some tens of protocols that use > > cryptographic algorithms. Some use one registry, others use another, > > some use no registry at all, some use OIDs and so on. > > > that's absolutely right, but it is worth mentioning that there is an > IETF registry for crypto algorithms that is used across several > different protocols: the Authenticated Encryption registry defined in > RFC 5116 > > that is used in TLS 1.2 (RFC 5246), IKEv2 (RFC 5282), SSH (RFC 5647), Um, no. RFC5647 is not SSH; it is AES-GCM for SSH. This is indeed an AEAD mode, and it borrows terminology from RFC5116, but so far as I know it does not use the AEAD algorithms registry, and SSH itself certainly does not; it has its own registries for each of the algorithm types it uses. -- Jeff From mcgrew@cisco.com Tue Nov 15 17:27:03 2011 Return-Path: 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 A1E6D1F0C73 for ; Tue, 15 Nov 2011 17:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.406 X-Spam-Level: X-Spam-Status: No, score=-106.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVFELkyxHANt for ; Tue, 15 Nov 2011 17:26:59 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 33CCD1F0C61 for ; Tue, 15 Nov 2011 17:26:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=1917; q=dns/txt; s=iport; t=1321406819; x=1322616419; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=zYRueHdD87ouo3hP4l7I+6As6RoMHr+kBLOIy+jLZSs=; b=JhvfeThf/d0pJ+FgwJOzj6psrfFeOfulnsLVlfiepZak7pxo3f6FnuKH nKSQuCLuzXeH2n2k0wyOW1k1tjaHs+MpZSla5teya10etbMFcyZRMtPE/ Fv822gX881jYnp9j17BLJ7GS230B+sk4R6Ci7KU9zHxkhTNCMagL9zr+n g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAkRw06rRDoG/2dsb2JhbABDDqlkgQWBcgEBAQMBEgElAj8FCwsOCi5XBhwZh2AImlIBnlOJLmMEiBOMH4U7jAhY X-IronPort-AV: E=Sophos;i="4.69,518,1315180800"; d="scan'208";a="14517569" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 16 Nov 2011 01:26:59 +0000 Received: from [10.32.254.210] ([10.32.254.210]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAG1Qvhs017811; Wed, 16 Nov 2011 01:26:58 GMT Message-Id: <2F7D5559-BCFC-4173-8D65-CF4509161184@cisco.com> From: David McGrew To: Jeffrey Hutzelman In-Reply-To: <1321400709.5944.48.camel@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 15 Nov 2011 17:26:56 -0800 References: <25866_1321399763_pAFNTMaK001839_7EB95733-E3E1-4876-B977-E6B696433B6B@cisco.com> <1321400709.5944.48.camel@minbar.fac.cs.cmu.edu> X-Mailer: Apple Mail (2.936) Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 01:27:03 -0000 Hi Jeff, On Nov 15, 2011, at 3:45 PM, Jeffrey Hutzelman wrote: > On Tue, 2011-11-15 at 15:29 -0800, David McGrew wrote: >> Hi Philip, >> >> On Nov 15, 2011, at 9:16 AM, Phillip Hallam-Baker wrote: >> >>> This issue keeps coming up. I think that events are converging in a >>> way that forces us to finally do something. >>> >>> >>> At present the IETF has some tens of protocols that use >>> cryptographic algorithms. Some use one registry, others use another, >>> some use no registry at all, some use OIDs and so on. >> >> >> that's absolutely right, but it is worth mentioning that there is an >> IETF registry for crypto algorithms that is used across several >> different protocols: the Authenticated Encryption registry defined in >> RFC 5116 >> >> that is used in TLS 1.2 (RFC 5246), IKEv2 (RFC 5282), SSH (RFC 5647), > > Um, no. RFC5647 is not SSH; it is AES-GCM for SSH. right. > This is indeed an > AEAD mode, and it borrows terminology from RFC5116, but so far as I > know > it does not use the AEAD algorithms registry, and SSH itself certainly > does not; it has its own registries for each of the algorithm types it > uses. Right, SSH does not define a way to negotiate any AEAD algorithm, though it does have an AEAD interface. Instead, it adds two entries from the AEAD registry to the SSH registry. Future standards work could easily extend this by defining a similar binding between entries from the AEAD registry and the SSH registry. I did not mean to imply that there are protocols that negotiate AEAD algorithms using entries from the IANA registry. Not yet anyway, though it would be a security improvement and a simplification to do away with independent registries and negotiation for authentication and encryption. David > > -- Jeff > > From hallam@gmail.com Tue Nov 15 21:42:04 2011 Return-Path: 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 2959F1F0D0E for ; Tue, 15 Nov 2011 21:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-9ttROoGk4X for ; Tue, 15 Nov 2011 21:41:59 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92CCA1F0CF8 for ; Tue, 15 Nov 2011 21:41:57 -0800 (PST) Received: by yenq4 with SMTP id q4so5972180yen.31 for ; Tue, 15 Nov 2011 21:41:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W+2mz7Z15DDnvbKW2f57rPs6ly9OIUcXwifpF4DgfnY=; b=TndABwVaTSw4OyCpTRV9QNsvxe0Nx8pkCyDZRHQkVOWTLhFLlf87fBGEheTFgZKRB+ C06oXikIJWeZQfe2pbdnjvnP/DA276ueufeCgUcBWXb5hiqjB99mnpNbLq8VvyOh6rNR hsMhMXsmglzlxSPAm6FBLYNW6l2xPp8xZsLY8= MIME-Version: 1.0 Received: by 10.182.111.8 with SMTP id ie8mr6723813obb.50.1321422116613; Tue, 15 Nov 2011 21:41:56 -0800 (PST) Received: by 10.182.42.99 with HTTP; Tue, 15 Nov 2011 21:41:55 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Nov 2011 00:41:55 -0500 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=14dae9399c99dbef4e04b1d38ff3 Cc: saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 05:42:04 -0000 --14dae9399c99dbef4e04b1d38ff3 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 15, 2011 at 5:58 PM, Nico Williams wrote: > On Tue, Nov 15, 2011 at 3:09 PM, Phillip Hallam-Baker > wrote: > > On Tue, Nov 15, 2011 at 1:06 PM, Nico Williams > > wrote: > >> On Tue, Nov 15, 2011 at 11:16 AM, Phillip Hallam-Baker < > hallam@gmail.com> > >> wrote: > >> But different WGs will have different perspectives on certain matters. > >> Should Camellia be specified for TLS, Kerberos, SSH, ...? Should it > >> be mandatory-to-implement? If not, should it be published on the > >> Informational track, or the Standards Track? > > > > I do not think that is actually true. > > In what circumstances would we want to endorse an algorithm for protocol > A > > knowing that it is not suitable for protocol B? > > We currently let each WG decide on its own. That is true but irrelevant. In what case would TLS accept Camilla as a preferred or mandatory to implement algorithm if it was not capable of being used in S/MIME, IPSEC and the rest? This is a standards organization and one of the reasons that we work as we do is that there is an idea that TLS and S/MIME and IPSEC and the rest all have an overlap that is important. There is a presumption that we are trying to find a common approach. If a WG has a really good reason to consider a non IETF standard algorithm then that is fine. But I have listened to these discussions for years now and I have yet to ever hear a good reason for an IETF protocol to employ DIY crypto. The argument has always centered on what the state of the art is for crypto in general. -- Website: http://hallambaker.com/ --14dae9399c99dbef4e04b1d38ff3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Nov 15, 2011 at 5:58 PM, Nico Wi= lliams <nico@= cryptonector.com> wrote:
On Tue, Nov 15, 2011 at 3:09 PM, Phillip Hallam-Baker <= ;hallam@gmail.com> wrote:
> On Tue, Nov 15, 2011 at 1:06 PM, Nico Williams <nico@cryptonector.com>
> wrote:
>> On Tue, Nov 15, 2011 at 11:16 AM, Phillip Hallam-Baker <hallam@gmail.com>
>> wrote:
>> But different WGs will have different pers= pectives on certain matters.
>> =A0Should Camellia be specified for TLS, Kerberos, SSH, ...? =A0Sh= ould it
>> be mandatory-to-implement? =A0If not, should it be published on th= e
>> Informational track, or the Standards Track?
>
> I do not think that is actually true.
> In what circumstances would we want to endorse an algorithm for protoc= ol A
> knowing that it is not suitable for protocol B?

We currently let each WG decide on its own.

That is true but irrelevant.

In what case w= ould TLS accept Camilla as a preferred or mandatory to implement algorithm = if it was not capable of being used in S/MIME, IPSEC and the rest?


This is a standards organization and one= of the reasons that we work as we do is that there is an idea that TLS and= S/MIME and IPSEC and the rest all have an overlap that is important. There= is a presumption that we are trying to find a common approach.

If a WG has a really good reason to consider a non IETF= standard algorithm then that is fine. But I have listened to these discuss= ions for years now and I have yet to ever hear a good reason for an IETF pr= otocol to employ DIY crypto. The argument has always centered on what the s= tate of the art is for crypto in general.

=A0
--
Website: http://hallambaker.com/

--14dae9399c99dbef4e04b1d38ff3-- From pgut001@login01.cs.auckland.ac.nz Tue Nov 15 22:53:00 2011 Return-Path: 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 4864A11E815A for ; Tue, 15 Nov 2011 22:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rn5b8QCXrSVF for ; Tue, 15 Nov 2011 22:52:56 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0195911E8099 for ; Tue, 15 Nov 2011 22:52:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1321426376; x=1352962376; h=from:to:subject:cc:in-reply-to:message-id:date; bh=9ZK4uUOKuCYLtkaNjLdj1TABmFzLEePoQ3CYDtQArug=; b=pacAcUv1r7rB1ltW2wK4NUaht08mlJRWphjLBjyVtl9z0aVkPTO+vqlQ h52/4b6q+NlZmNP6s+sAEsebYW4Y/bcFUNDYjDl+yu3Av8oP8E2P2v4xN 7/kUgcbtkzEW531Gpgz+I7HubfurirItSbpVHxkn8UWzwTC5PHPm4lz38 I=; X-IronPort-AV: E=Sophos;i="4.69,519,1315137600"; d="scan'208";a="90545862" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.34.40 - Outgoing - Outgoing Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 16 Nov 2011 19:52:39 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1RQZMN-0004WH-I7; Wed, 16 Nov 2011 19:52:39 +1300 From: Peter Gutmann To: hallam@gmail.com, nico@cryptonector.com In-Reply-To: Message-Id: Date: Wed, 16 Nov 2011 19:52:39 +1300 Cc: saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 06:53:00 -0000 Phillip Hallam-Baker writes: >There is no shortage of cryptographic algorithms. I can't see why TLS should >even spend the time considering Camellia if there was any doubt about the >ability to use it in IPSEC. The situation with Camellia (and several others) is even messier than that. These are present in protocols purely as fashion statements, so there's no easy way you can make any technical statements about them ("this algorithm is used here because ..." or "... not used here because ..."). OTOH it's also unlikely that their contributors are going to be happy having them listed in some registry as "present in order to make a fashion statement" (NB: "Present because the government of Elbonia mandates it for use in Elbonia" is just a roundabout way of saying that it's a fashion-statement algorithm, so that doesn't work as an excuse either). I have no idea how you'd deal with this once you start going beyond the currently-employed ostrich algorithm. Peter. From shawn.emery@oracle.com Tue Nov 15 23:14:18 2011 Return-Path: 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 8EBE011E81E4 for ; Tue, 15 Nov 2011 23:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOYEud5UKvCg for ; Tue, 15 Nov 2011 23:14:17 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6D63B11E81E8 for ; Tue, 15 Nov 2011 23:14:17 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAG7EFip007314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 16 Nov 2011 07:14:16 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pAG6w1ic019090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Nov 2011 07:14:15 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pAG5A63g014199 for ; Tue, 15 Nov 2011 23:10:07 -0600 Received: from dhcp-1599.meeting.ietf.org (/130.129.21.153) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 15 Nov 2011 21:10:06 -0800 Message-ID: <4EC345AC.5030301@oracle.com> Date: Tue, 15 Nov 2011 22:10:04 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: saag@ietf.org References: <4EC31D86.6060006@oracle.com> In-Reply-To: <4EC31D86.6060006@oracle.com> X-Forwarded-Message-Id: <4EC31D86.6060006@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A020206.4EC362C8.0093,ss=1,re=0.000,fgs=0 Subject: [saag] kitten Summary - IETF 82 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 07:14:18 -0000 Co-chairs: Tom Yu, Shawn Emery, and Alexey Melnikov The WG met in the 3rd afternoon session on Tuesday (11.15.11). There were four presentations on work/charter items as follows: Naming Extensions Comments -------------------------- Issues were raised during WGLC on the naming extensions draft; there is no form of enforcing criticality when asserting naming attributes. Proposed solution by Nico Williams involves inquiring the credential handle to verify that said name attribute was set. The caller can inference this after context establishment. SASL-OpenID Issues ------------------ Problems were found during Gen-ART and secdir review. The Gen-ART review raised issues with downward references made to OpenID specifications. The stability level of said reference, in regards to any future versioning and availability, was in question. Authors will discuss with OpenID on guaranteeing stability level for these references. secdir review cited several clarifying issues which were agreed upon and mostly resolved. SASL-OAuth Changes ------------------ There were a number of proposed changes/questions on the OAuth draft including which form (HTTP-Style or native), security functionality (Bearer Token, Public Key, MAC), and discovery method (native SASL or separate mechanism). There wasn't enough time to take consensus on the topics in the room, so we will take this to the list. GSS-API Memory Management Issues -------------------------------- Sam Hartman discussed issues found when dealing with various platforms regarding memory management. He believes that these problems could be resolved w/o changing the API or adding new ones. E-mail will be sent to the list to start this discussion that the various mechanism implementers can determine is this will address their instance. Shawn. -- From simon@josefsson.org Tue Nov 15 23:27:34 2011 Return-Path: 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 B153021F920C for ; Tue, 15 Nov 2011 23:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.048 X-Spam-Level: X-Spam-Status: No, score=-102.048 tagged_above=-999 required=5 tests=[AWL=-2.139, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTpiQzma9Coe for ; Tue, 15 Nov 2011 23:27:34 -0800 (PST) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id E116D21F91F4 for ; Tue, 15 Nov 2011 23:27:32 -0800 (PST) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id pAG7RGqu020023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 16 Nov 2011 08:27:18 +0100 From: Simon Josefsson To: Phillip Hallam-Baker References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:111116:saag@ietf.org::P/bAIRej3CqXUyT3:NLg X-Hashcash: 1:22:111116:nico@cryptonector.com::JcBdX/R35nu8ZZ6P:20PM X-Hashcash: 1:22:111116:hallam@gmail.com::XTJzkAI34W4pjizM:KFZd Date: Wed, 16 Nov 2011 08:27:16 +0100 In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 15 Nov 2011 16:09:00 -0500") Message-ID: <87sjlo4je3.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 07:27:34 -0000 Phillip Hallam-Baker writes: > There is no shortage of cryptographic algorithms. I can't see why TLS > should even spend the time considering Camellia if there was any doubt > about the ability to use it in IPSEC. The only algorithms I can ever see > being worth consideration at this point would be ones that are sufficiently > general purpose that they can be used in multiple protocols. > > What I am proposing instead is a low bar to making Camellia an option in > any IETF protocol. I believe this to be a Pareto improvement as follows: > > * The developers of Camellia can get their algorithm enabled as an option > in all IETF protocols in a single operation. The situation with Camellia has another angle to it: the patent statements about it only applies to specific protocols, and there are now statements for (at least) TLS and Kerberos. If Camellia is to be considered for any other protocol, a new patent disclosure is required. So Camellia is not intended to be a general purpose cipher. Personally, I find this limiting enough that I believe we should not waste precious review and process time on it. Time that could be spent on standardizing non-encumbered algorithms. /Simon From jsalowey@cisco.com Wed Nov 16 01:43:00 2011 Return-Path: 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 C882021F94A4; Wed, 16 Nov 2011 01:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fe8AESElMEyR; Wed, 16 Nov 2011 01:43:00 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEBE21F94E2; Wed, 16 Nov 2011 01:42:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=845; q=dns/txt; s=iport; t=1321436577; x=1322646177; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=PZ8Ep+1hIQPPfuX6+7vMBK3JYH0dLyYdpBDCtCqEn4w=; b=fk77bs7rUCOKgX5joGfKHGFJVoxYQE1kp9C9G/HShr3id1g8PChshCMV nmF3scMxiDl1ywNEdUjBmO54WvbXKHGdDS9XMzsEknknetGwkJXiplBI+ i2aekArs65tydQCygIa1uPRuDk8EamZmL1kjELg9odQUeXFQg70DwG4Ct Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsMAOeEw05Io8UR/2dsb2JhbAAiIalzgQWCCwEnP4FzoioBnlqHAoIyYwSIFIwgkh0 X-IronPort-AV: E=Sophos;i="4.69,520,1315180800"; d="scan'208";a="3201666" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-4.cisco.com with ESMTP; 16 Nov 2011 09:42:55 +0000 Received: from dhcp-1319.meeting.ietf.org (hkidc-vpn-client-234-6.cisco.com [10.75.234.6]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAG9gsLZ014202; Wed, 16 Nov 2011 09:42:54 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 01:42:52 -0800 Message-Id: <8BA59309-C0A2-4F78-BA3C-99753D764EA9@cisco.com> To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: emu@ietf.org Subject: [saag] IETF 82 EMU working group meeting summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 09:43:01 -0000 EMU met on Tuesday morning. EAP Channel bindings = (draft-ietf-emu-chbind-11) completed working group last call and a new = draft has been issued incorporating most of the comments. There are a = few open issues so another revision will be needed before forwarding to = IESG. Open issues on the EAP tunnel method (currently called TEAP - = draft-ietf-emu-eap-tunnel-method-01) were discussed. Proposed = resolutions from the meeting will be raised on the working group list. = We had discussion on the update of the EAP applicability statement in = draft-winter-abfab-eapapplicability-01which is currently a charter item = in the ABFAB working group. There is some question on whether this work = should be done in EMU or ABFAB as the document will need review from = both ABFAB and EMU and other groups such as NEA. =20 From pgut001@cs.auckland.ac.nz Wed Nov 16 02:58:05 2011 Return-Path: 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 5B32A21F94CB for ; Wed, 16 Nov 2011 02:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvqfNB4VDknW for ; Wed, 16 Nov 2011 02:58:04 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 137A221F94C9 for ; Wed, 16 Nov 2011 02:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1321441084; x=1352977084; h=from:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=iViGOeDu1xX8hzJx1zsOKfPeogdovdJ/F1EQ2aKzipk=; b=WsUuF7l9zU+/DkuZcs79pfwWBd60DuVZ5amebgevuUXNQq7D3IrGxIH7 E3kXhaGWAnVukyz7v5LFZuq97Di9knh0i7KTgsgKHt+sJ5ZztiHp97b+B 1KiMxIwIJbK9+Y9udp/RcWJl00WwNkBzIwy2cTrdmczDCO1LmEOBFW+Aw E=; X-IronPort-AV: E=Sophos;i="4.69,520,1315137600"; d="scan'208";a="90559153" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.itsys.auckland.ac.nz (HELO uxchange10-fe2.UoA.auckland.ac.nz) ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 16 Nov 2011 23:58:00 +1300 Received: from UXCN10-1.UoA.auckland.ac.nz ([169.254.1.62]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.01.0289.001; Wed, 16 Nov 2011 23:58:00 +1300 From: Peter Gutmann CC: "saag@ietf.org" Thread-Topic: [saag] Proposal to Consolidate Algorithms Registries Thread-Index: AcykTpqMD+ZU00xvQ0Cs1yqcrFxirQ== Date: Wed, 16 Nov 2011 10:57:59 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73419634@uxcn10-1.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.11.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 10:58:05 -0000 Phillip Hallam-Baker writes:=0A= =0A= >There is no shortage of cryptographic algorithms. I can't see why TLS shou= ld=0A= >even spend the time considering Camellia if there was any doubt about the= =0A= >ability to use it in IPSEC.=0A= =0A= The situation with Camellia (and several others) is even messier than that.= =0A= These are present in protocols purely as fashion statements, so there's no= =0A= easy way you can make any technical statements about them ("this algorithm = is=0A= used here because ..." or "... not used here because ..."). OTOH it's also= =0A= unlikely that their contributors are going to be happy having them listed i= n=0A= some registry as "present in order to make a fashion statement" (NB: "Prese= nt=0A= because the government of Elbonia mandates it for use in Elbonia" is just a= =0A= roundabout way of saying that it's a fashion-statement algorithm, so that= =0A= doesn't work as an excuse either).=0A= =0A= I have no idea how you'd deal with this once you start going beyond the=0A= currently-employed ostrich algorithm.=0A= =0A= Peter.=0A= From mcgrew@cisco.com Wed Nov 16 06:05:22 2011 Return-Path: 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 29A6121F965A for ; Wed, 16 Nov 2011 06:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.414 X-Spam-Level: X-Spam-Status: No, score=-106.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3ugs90+yhda for ; Wed, 16 Nov 2011 06:05:21 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6410621F94FF for ; Wed, 16 Nov 2011 06:05:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2935; q=dns/txt; s=iport; t=1321452321; x=1322661921; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=BYzsq1ABKjm4/YOw+m9ATku4/O57gGIxBW5dxmNs5hc=; b=hFXq7hdQF4tqAmaylNQWa1fizno+knyhswvSpcoZ9R5BaDoUtkuiHpgO onkZHGUL2kldhIgYXfl0cFH0/UeiKtPQz+8yRH7OntA27G0EasX8rKv3R 2ukGw1Y4iK57LS2tmtCSgLq8gWt9s+4STJWc1R9ZGpeuE0cLriLfV5QMv M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAADCw06rRDoH/2dsb2JhbABDqXeBBYFyAQEBAgEBAQEBDwElAjQLBQsLRiEGMAYTGgiHYAiaJwGeYYk0YwSIFIwghTuFEIdS X-IronPort-AV: E=Sophos;i="4.69,521,1315180800"; d="scan'208";a="14621855" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 16 Nov 2011 14:05:21 +0000 Received: from [10.32.254.210] ([10.32.254.210]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAGE5KO2005039; Wed, 16 Nov 2011 14:05:20 GMT Message-Id: From: David McGrew To: Simon Josefsson In-Reply-To: <87sjlo4je3.fsf@latte.josefsson.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 16 Nov 2011 06:05:19 -0800 References: <87sjlo4je3.fsf@latte.josefsson.org> X-Mailer: Apple Mail (2.936) Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 14:05:22 -0000 Hi Phillip, On Nov 15, 2011, at 11:27 PM, Simon Josefsson wrote: > Phillip Hallam-Baker writes: > >> There is no shortage of cryptographic algorithms. I can't see why TLS >> should even spend the time considering Camellia if there was any >> doubt >> about the ability to use it in IPSEC. The only algorithms I can >> ever see >> being worth consideration at this point would be ones that are >> sufficiently >> general purpose that they can be used in multiple protocols. >> >> What I am proposing instead is a low bar to making Camellia an >> option in >> any IETF protocol. I believe this to be a Pareto improvement as >> follows: >> >> * The developers of Camellia can get their algorithm enabled as an >> option >> in all IETF protocols in a single operation. > > The situation with Camellia has another angle to it: the patent > statements about it only applies to specific protocols, and there are > now statements for (at least) TLS and Kerberos. If Camellia is to be > considered for any other protocol, a new patent disclosure is > required. > So Camellia is not intended to be a general purpose cipher. This is a good point. I had not realized all of the IPR nuances around this cipher. NTT declared back in 2001 that it "intends to grant royalty-free licenses" for Camellia [1] but apparently on a protocol-by-protocol basis, and the IPsec case includes a reciprocity requirement [2]. Perhaps the Camellia sponsors can prod a broad IPR declaration from the IPR holders? It looks like the IPR situation for Camellia is not captured in the datatracker tools. The only Camellia RFC that I found that has an IPR link is the TLS one, RFC 6367, and that link is not about Camellia IPR! > > Personally, I find this limiting enough that I believe we should not > waste precious review and process time on it. Time that could be > spent > on standardizing non-encumbered algorithms. > Agreed. Any algorithm that seeks broad acceptance needs to be available royalty-free around the world. There is an available pool of such ciphers that were created during the AES process (serpent, twofish, ...) plus some other more modern IPR-free ciphers that could be used to achieve algorithm diversity in standards. The IETF needs to be clear and firm in not mandating the implementation of patent- encumbered ciphers. David [1] "Announcement of Royalty-free Licenses for Essential Patents of NTT Encryption and Digital Signature Algorithms" [2] NTT-Mitsubishi Patent Licensing Statment for Camellia > /Simon > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From mcgrew@cisco.com Wed Nov 16 07:04:38 2011 Return-Path: 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 7394F21F965B for ; Wed, 16 Nov 2011 07:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.424 X-Spam-Level: X-Spam-Status: No, score=-106.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mhHWiXYybNk for ; Wed, 16 Nov 2011 07:04:37 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD541F0C7F for ; Wed, 16 Nov 2011 07:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=9427; q=dns/txt; s=iport; t=1321455877; x=1322665477; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=lYwqTXohc81ZcYU/7A3PQTxdox+m7l0ozOykeHY2amM=; b=LzTpr6TUGiyweOuWQTUwTdgCu+SOM+BBbBkTSgClBvtMSu2EzYagZdTg XPM761o9V+u4eX5kqPDAkRB7IE1dYF/68WTid6rABd8n8Yqs1StbC1Xu5 wfR6oOkDZS4mv99aiYfqvas0JKPa437kcWa1GGk0z4iw4NqWAX9ev22lK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEFAHrQw06rRDoG/2dsb2JhbABDpxSCY4EFgXIBAQEDAQEBAQ8BJQIyAggDBQsLGC4hBjAGEyKHYAiaMQGeYgSJNGMEiBSMIIU7hRCHUg X-IronPort-AV: E=Sophos;i="4.69,521,1315180800"; d="scan'208";a="12864051" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 16 Nov 2011 15:04:36 +0000 Received: from [10.32.254.210] ([10.32.254.210]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAGF4ZBb014882; Wed, 16 Nov 2011 15:04:35 GMT Message-Id: From: David McGrew To: Nico Williams In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 16 Nov 2011 07:04:34 -0800 References: X-Mailer: Apple Mail (2.936) Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 15:04:38 -0000 Hi Nico, On Nov 15, 2011, at 10:06 AM, Nico Williams wrote: > On Tue, Nov 15, 2011 at 11:16 AM, Phillip Hallam-Baker > wrote: >> 2) There is no process for maintaining algorithms after a WG has >> closed. > > Sure there is! It's whatever process that WG's core documents outline > for registration, else the IETF process (individual submissions, find > another suitable WG, start a new WG) > >> 3) Duplication of effort. >> What point is served by having the same conversation about which >> algorithms >> to use in 10 different WGs? Modern machines are (mostly) pretty >> capable and >> there are almost no cases where an individual WG need be making >> protocol >> specific choices of algorithm to meet performance or space goals. > > But different WGs will have different perspectives on certain matters. > Should Camellia be specified for TLS, Kerberos, SSH, ...? Should it > be mandatory-to-implement? If not, should it be published on the > Informational track, or the Standards Track? > > Answers to these sorts of questions are allowed to vary by WG right > now. Perhaps that is a problem, but if not, do we want to lose > whatever value we get from being able to answer those questions on a > WG-by-WG basis? > > And if you propose that things like "mandatory-to-implement" be > protocol-specific, but all in the same registration entry, should > registration be held up until we have consensus for each protocol, or > should registrations be updated lazily for each protocol? (I would > hope the latter.) Would we have a single list/WG for consensus, or > would we still need to do whatever is appropriate for each protocol > (e.g., use concluded WG lists)? > > (I'm not nay-saying here. These are questions to which I see > potentially satisfactory answers.) > > It might make sense to limit this new registry to just a few protocols > (PKIX, TLS, CMS, leaving out Kerberos, SSH?), then add the remaining > protocols as we gain experience with the new registry. But even so, I > think we want some idea of what the registry and registration process > will look like when we're done. > That's a practical suggestion. > Also, it'd be nice if we always had an explicit sequence number in all > *new* cipher suites, even when a given protocol only requires an octet > stream, as TLS and SSH do. DTLS obviously needs this, but it wouldn't > hurt SSH, and we really want to never again have modes like chained-IV > CBC. +1 > This wouldn't be a big change for SSH as it already has this for > counter-mode ciphers, basically. It wouldn't be much of a change for > GSS-API mechanisms either. But this would be a much more disruptive > change for Kerberos. Perhaps the thing to do would be to leave our > Kerberos... > I think that what you mean could be said as: the crypto algorithm should be responsible for the IV or nonce, and not the protocol. I think that's a great idea. > The one thing we don't want is to make addition of crypto algorithms > so difficult that it takes years [more than now] or worse: never > happens. +1 > This is the biggest scare factor for me regarding your > unified registry proposal. > >> 4) Inconsistency >> Using two different crypto algorithms provides the strength of the >> weakest >> one. Inconsistency is almost always worse than a sub-optimal >> choice. I don't >> much care what the RSA signature format used is as long as it is >> 'good >> enough' for me and 'everyone' is using it. > > The security of the whole is certainly affected by the strength of > individual algorithms, but the way in which the whole is put together > is critical as well. SHA-1 may suck now, but HMAC-SHA-1 is still > considered secure enough. That's one example. The 'whole' consists > of key exchange, authentication, KDF/PRF, ciphers, cipher modes, and > integrity protection algorithms (except when an AE/AEAD cipher mode > takes care of the last), and the way in which these are all combined. > >> We should make these choices once and have the consequences flow >> out to all >> the protocols that use the algorithms. > > The 'whole' does vary significantly by protocol because, sadly, the > protocols themselves vary so much (or have protocol-specific details > that are difficult to abstract). Thus I have a hard time imagining > that a shared registry will be enough to allow us to easily analyze > and/or ensure the security of our protocols, say. > > I'm not saying that I don't want a unified theory of crypto protocol, > complete with unified algorithm registry. Quite the contrary, I do. > I just think there's a lot of work to do to get there. Again, maybe > if you start small? > > Or perhaps start with an informative registry and see if we can > eventually get each protocol to switch to it as their normative > registry as we gain experience? +1 > >> 5) 'Vanity' Crypto and other non-Mandatory algorithms. >> Cryptography has always been a highly politicized technology. In >> recent >> decades it has been as highly politicized as nuclear power and for >> much the >> same reason: Cryptography was one of the principle technologies >> that decided >> the outcome of WWII and was thus a key technology in the cold war. >> The politics behind so-called vanity crypto are very complex and I >> don't >> really want to go into them here. What I wat to do instead is to >> build a >> firewall so that the IETF does not need to get dragged into those >> politics. > > Making vanity crypto decisions global to a set of protocols will > probably complicate the politics of selecting mandatory-to-implement > algorithms. Or perhaps I'm wrong and implementors (and therefore, the > IETF) will throw in the towel and accept a large number of > mandatory-to-implement algorithms. We probably can't tell without > trying. > > However, though we have lots of deja vu moments today in each > protocol/WG, we do benefit from being able to make different MTI > decisions in each case (i.e., implementors for each protocol are only > affected by consensus for that protocol, not global consensus). There may be a role for a "global" decision here. The only important technical argument for recommending the implementation of more than one cipher is to provide for security through algorithm diversity. It might make sense to select an alternate cipher to the AES to act as a standby in case of unanticipated future advances in cryptanalysis. If we do this, it would be best to select a single algorithm, which could have a status on Phillip's list somewhere below MUST-implement but above MAY-implement. Any process used for the selection of a standby should meet the same stringent criteria for extensive public review and analysis as the AES did, and should meet all of the criteria set out for the AES: security, computational efficiency, memory requirements, hardware and software suitability, simplicity, flexibility, and licensing requirements. In particular, it should be available worldwide on a royalty-free basis. Since the major goal of a standby cipher is to be secure even if the AES proves vulnerable to future advances in cryptanalysis, the standby algorithm should not follow a design strategy that is identical to that of the AES. Or perhaps a better way to state the last requirement is: a standby algorithm should have a sound technical argument why it would survive advances in cryptanalysis that would be damaging to the AES. The other technical arguments for multiple ciphers are performance/ implementation cost, and interoperability during transitions. I don't think performance and cost should be a determining factor for the majority of IETF work. If those considerations prove to be important for constrained environments, say, they can and should be treated as a special case (which is consistent with your suggestion to focus on the main IETF cryptographic protocols). Interoperability between algorithm transitions (say, from DES to 3DES to AES) clearly isn't pertinent to the selection of new algorithms. David > >> For historical reasons, the IETF preferred algorithms are >> essentially the >> NSA/NIST choices. One approach would be for the IETF to only >> recognize those >> and no others. This is probably not sustainable. Registries such as >> IANA are >> [...] > > Our preferred algorithms are historical accidents, yes, but ultimately > they have to do with consensus and available choices at the time that > the choices had to be made. I.e., we have a bit of an accidental > first-com-first-served policy, and that implicit policy has been > becoming much more of an explicit policy recently (it's convenient > that we can interpret the past this way, I know). If we were to have > too many algorithms to choose from when we need to choose we'd simply > have more interesting discussions -- or are you saying we might then > fail to reach consensus? But how would a single registry make it more > possible to reach consensus in such a situation?? > > Nico > -- > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From mcgrew@cisco.com Wed Nov 16 07:27:19 2011 Return-Path: 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 2A2E221F945B for ; Wed, 16 Nov 2011 07:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.433 X-Spam-Level: X-Spam-Status: No, score=-106.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAmboRNH8uBi for ; Wed, 16 Nov 2011 07:27:18 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 875AE21F9456 for ; Wed, 16 Nov 2011 07:27:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=1507; q=dns/txt; s=iport; t=1321457238; x=1322666838; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=hmiYARBjiNEQgC7N5V9B4g3ERPA3RXGWtJ/4HvkLa28=; b=IRF5MR9P6lwF6w3Y9ndz3RA140TwzCmcyZq2rsmI2Jg8qWhrTY8lLC13 hMAySDGLFnp2hEuB9wNT8fv/EcBjkzYbJL7nJt68pElG9m/CnAKrHvAVP 2mUss0KpGaV4Ze3SWqXNx1dkwiUdRPXFp0r1ch8v3j/4pkeUV4RtjlkGT U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEnVw06rRDoG/2dsb2JhbABDDqlpgQWBcgEBAQQSASUCPxALDgouVwY1oi0Bnm2JNGMEiBSMIIU7jApY X-IronPort-AV: E=Sophos;i="4.69,521,1315180800"; d="scan'208";a="12868355" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 16 Nov 2011 15:27:18 +0000 Received: from [10.32.254.210] ([10.32.254.210]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAGFRHQa027865; Wed, 16 Nov 2011 15:27:17 GMT Message-Id: From: David McGrew To: Jeffrey Hutzelman In-Reply-To: <1321395383.5944.41.camel@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 16 Nov 2011 07:27:16 -0800 References: <1416_1321391352_pAFL9AGV023452_CAMm+LwioQiF167ewRJAZoeB180MSH6SPkyWcG1XgKNJ0wsj+NQ@mail.gmail.com> <1321395383.5944.41.camel@minbar.fac.cs.cmu.edu> X-Mailer: Apple Mail (2.936) Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 15:27:19 -0000 Hi Jeffrey, On Nov 15, 2011, at 2:16 PM, Jeffrey Hutzelman wrote: > On Tue, 2011-11-15 at 16:09 -0500, Phillip Hallam-Baker wrote: >> The number of mandatory to implement algorithms should usually be one > > People keep saying that, but in fact I think that's a horrible > idea. If > you only have one MTI algorithm, then when that algorithm is suddenly, > spectacularly broken, everyone is screwed. You can't just declare > some > new algorithm MTI, because that _doesn't solve the problem_. What > solves the problem is _deploying_ the new algorithm, and having to > wait > three years for the IETF to choose a new MTI algorithm and then for > vendors to implement, test, and ship it just doesn't cut it. > > In most cases we should have _at least two_ MTI algorithms whenever > possible, so that if one is broken we (operators) can simply turn it > off > and everything continues to work. > You have a valid point, though I am not convinced that two MUST- implement algorithms makes sense, considering how unlikely it is that AES will need to be replaced in the foreseeable future. But having an alternate algorithm declared SHOULD-implement might be reasonable, and that's not far from the direction you suggest here. An important factor: if an algorithm is selected for use as a standby to the AES, that imposes a particular set of technical criteria that it should meet. (My last post set these out, so I won't repeat them here.) David From kanno.satoru@po.ntts.co.jp Wed Nov 16 15:55:29 2011 Return-Path: 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 CD2051F0C35 for ; Wed, 16 Nov 2011 15:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ReKMpMUKqCF for ; Wed, 16 Nov 2011 15:55:29 -0800 (PST) Received: from mail12.ics.ntts.co.jp (mail12.ics.ntts.co.jp [210.232.35.65]) by ietfa.amsl.com (Postfix) with ESMTP id 335601F0C34 for ; Wed, 16 Nov 2011 15:55:28 -0800 (PST) Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail12.ics.ntts.co.jp (8.14.4/8.13.4/NTTSOFT) with ESMTP id pAGNtFBq008386; Thu, 17 Nov 2011 08:55:15 +0900 (JST) Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id pAGNtFuQ020127; Thu, 17 Nov 2011 08:55:15 +0900 (JST) Received: from ccmds32.silk.ntts.co.jp [10.107.0.32] by sadoku34.silk.ntts.co.jp with SMTP id JAA20126; Thu, 17 Nov 2011 08:55:15 +0900 Received: from mail147.silk.ntts.co.jp (ccmds32.silk.ntts.co.jp [127.0.0.1]) by ccmds32.silk.ntts.co.jp (8.14.3/8.14.3) with ESMTP id pAGNtFR7005809; Thu, 17 Nov 2011 08:55:15 +0900 Received: from mail147.silk.ntts.co.jp (localhost.localdomain [127.0.0.1]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with ESMTP id pAGNtAn8020546; Thu, 17 Nov 2011 08:55:10 +0900 Received: from ccmds32 (mail145.silk.ntts.co.jp [10.107.0.145]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with SMTP id pAGNtAbN020543; Thu, 17 Nov 2011 08:55:10 +0900 Message-ID: <4EC44D40.1000703@po.ntts.co.jp> Date: Thu, 17 Nov 2011 08:54:40 +0900 From: Satoru Kanno User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Simon Josefsson References: <87sjlo4je3.fsf@latte.josefsson.org> In-Reply-To: <87sjlo4je3.fsf@latte.josefsson.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: CC-Mail-V4.3-Client X-CC-Mail-RelayStamp: CC-Mail-V4.3-Server Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 23:55:29 -0000 Hi Simon and Phillip, (2011/11/16 16:27), Simon Josefsson wrote: > Phillip Hallam-Baker writes: > >> There is no shortage of cryptographic algorithms. I can't see why TLS >> should even spend the time considering Camellia if there was any doubt >> about the ability to use it in IPSEC. The only algorithms I can ever see >> being worth consideration at this point would be ones that are sufficiently >> general purpose that they can be used in multiple protocols. >> >> What I am proposing instead is a low bar to making Camellia an option in >> any IETF protocol. I believe this to be a Pareto improvement as follows: >> >> * The developers of Camellia can get their algorithm enabled as an option >> in all IETF protocols in a single operation. > > The situation with Camellia has another angle to it: the patent > statements about it only applies to specific protocols, and there are > now statements for (at least) TLS and Kerberos. If Camellia is to be > considered for any other protocol, a new patent disclosure is required. > So Camellia is not intended to be a general purpose cipher. > Up to now, because we proposed adding the Camellia cipher to each protocols, we filed the Camellia IPRs for the relevant WGs. If IETF changes the policy of addition of cipher algorithms to new one, of course, NTT & Mitsubishi intend to file for the revised general-purpose IPR which permits to use Camellia cipher in any protocols in IETF. Thanks, Satoru > Personally, I find this limiting enough that I believe we should not > waste precious review and process time on it. Time that could be spent > on standardizing non-encumbered algorithms. > > /Simon > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- Satoru Kanno Security Business Unit Mobile and Security Solution Business Group NTT Software Corporation e-mail: kanno.satoru@po.ntts.co.jp From ietf@augustcellars.com Tue Nov 15 20:14:46 2011 Return-Path: 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 0761C11E80AA; Tue, 15 Nov 2011 20:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Byx3IxH2pUpr; Tue, 15 Nov 2011 20:14:45 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4A01F0C4B; Tue, 15 Nov 2011 20:14:45 -0800 (PST) Received: from Tobias (dhcp-10a6.meeting.ietf.org [130.129.16.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id D44FF38F0C; Tue, 15 Nov 2011 20:14:44 -0800 (PST) From: "Jim Schaad" To: Date: Wed, 16 Nov 2011 12:14:12 +0800 Message-ID: <039b01cca416$339d3bc0$9ad7b340$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AcykFRgfJsYbIQjZRJi0Q7ME09xAGA== X-Mailman-Approved-At: Wed, 16 Nov 2011 16:17:21 -0800 Cc: jose@ietf.org Subject: [saag] JOSE Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 04:14:46 -0000 JOSE met in the 1:00 slot on Monday for its first meeting as a newly formed working group. We were presented with three documents which are intended to be re-structured into the four documents that are called for by the charter. These documents are the result of work done outside of the IETF which are now being brought here for additional work. There were no objections in the meeting to using these documents as the basis for charter documents. New versions of the documents are expected within the next month which will be adopted as WG work items. An additional presentation followed by discussion in the room occurred in terms of the set of features that need to be supported by the JOSE work. Requests for features came from the floor from the XMPP and the ALTO working groups which are not presently supported. From kent@bbn.com Wed Nov 16 18:07:06 2011 Return-Path: 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 C71A01F0C44 for ; Wed, 16 Nov 2011 18:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsyOWtB18cHq for ; Wed, 16 Nov 2011 18:07:06 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6232521F87D9 for ; Wed, 16 Nov 2011 18:07:06 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:34597 helo=[172.20.1.65]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RQrNZ-0005Ta-OX for saag@ietf.org; Wed, 16 Nov 2011 21:07:06 -0500 Mime-Version: 1.0 Message-Id: Date: Wed, 16 Nov 2011 20:33:47 -0500 To: saag@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [saag] PKIX summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 02:07:06 -0000 PKIX did not meet at IETF 82. Steve From kent@bbn.com Wed Nov 16 18:20:35 2011 Return-Path: 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 D501211E808F for ; Wed, 16 Nov 2011 18:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.536 X-Spam-Level: X-Spam-Status: No, score=-106.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XChI711VEU8O for ; Wed, 16 Nov 2011 18:20:35 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 62AFC11E8081 for ; Wed, 16 Nov 2011 18:20:35 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:32814 helo=[172.20.1.65]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RQrac-000Nay-IK for saag@ietf.org; Wed, 16 Nov 2011 21:20:34 -0500 Mime-Version: 1.0 Message-Id: Date: Wed, 16 Nov 2011 21:20:25 -0500 To: saag@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [saag] PKIX stats update X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 02:20:36 -0000 Although PKIX did not meet this time, there has been progress since the Quebec meeting: - 5272bis (CMC updates) is in the RFC editors queue - S/MIME public key capabilities completed WGLC and is about to be forwarded to the IESG - the HTTP transport for CMP I-D has been updated - the CAA I-D has been updated - Max Pritkin has a coauthor for his EST I-D Steve From hallam@gmail.com Wed Nov 16 18:24:30 2011 Return-Path: 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 34AE911E80B0 for ; Wed, 16 Nov 2011 18:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7NvTiqtIsKA for ; Wed, 16 Nov 2011 18:24:25 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4320D1F0CAA for ; Wed, 16 Nov 2011 18:24:25 -0800 (PST) Received: by wwe5 with SMTP id 5so1661865wwe.13 for ; Wed, 16 Nov 2011 18:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZvZLG5nDDECaIfKAiNyTGMdO8UZ9S8KliMNaNlX/Mkc=; b=IeZY/iNEKYSQr7x0pKmeasA+GUppl2xjba6Mz7UL5k1IRZ3krdPfiBbik1Ee8Ff+YV Ch4EqtqsM4PQ4ZHuauR6gV1cyD/g9I53EU59duFBetrJMmvR0kW5ZP84IJDfBPL/Trag Qpf85OEMUIS7nuH2vZl33lZXayUPsxadsF7FA= MIME-Version: 1.0 Received: by 10.182.227.7 with SMTP id rw7mr9580752obc.70.1321496663139; Wed, 16 Nov 2011 18:24:23 -0800 (PST) Received: by 10.182.42.99 with HTTP; Wed, 16 Nov 2011 18:24:23 -0800 (PST) In-Reply-To: <87sjlo4je3.fsf@latte.josefsson.org> References: <87sjlo4je3.fsf@latte.josefsson.org> Date: Wed, 16 Nov 2011 21:24:23 -0500 Message-ID: From: Phillip Hallam-Baker To: Simon Josefsson Content-Type: multipart/alternative; boundary=f46d044472bb2da4b404b1e4eb4e Cc: saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 02:24:30 -0000 --f46d044472bb2da4b404b1e4eb4e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 16, 2011 at 2:27 AM, Simon Josefsson wrote: > Phillip Hallam-Baker writes: > > > There is no shortage of cryptographic algorithms. I can't see why TLS > > should even spend the time considering Camellia if there was any doubt > > about the ability to use it in IPSEC. The only algorithms I can ever see > > being worth consideration at this point would be ones that are > sufficiently > > general purpose that they can be used in multiple protocols. > > > > What I am proposing instead is a low bar to making Camellia an option in > > any IETF protocol. I believe this to be a Pareto improvement as follows: > > > > * The developers of Camellia can get their algorithm enabled as an option > > in all IETF protocols in a single operation. > > The situation with Camellia has another angle to it: the patent > statements about it only applies to specific protocols, and there are > now statements for (at least) TLS and Kerberos. If Camellia is to be > considered for any other protocol, a new patent disclosure is required. > So Camellia is not intended to be a general purpose cipher. > > Personally, I find this limiting enough that I believe we should not > waste precious review and process time on it. Time that could be spent > on standardizing non-encumbered algorithms. This seems to me to be an argument for having the decision made at the IETF level. If there are no IPR issues I don't particularly care whether Camilla is available for use in IPSEC or not. But if there is an IPR issue then I don't want to see it accepted for IPSEC unless it is available for TLS, S/MIME and everything else. I do not object to encumbered technology as an absolute principle but I see no reason to spend one minute of any WG time considering any encumbered technology that does not offer a clear and exceptionally compelling advantage over unencumbered alternatives. In this case there is a very clear disadvantage to having these negotiations made piecemeal on a WG by WG basis. I don't want to spend a minute in IPSEC if the result is going to be free for use in TLS and for future IETF protocols. The issue would be rather different if we were talking about a technology that does not have an unencumbered alternative at present. But we have a very good unencumbered alternative to Camilla so why spend any time on it (including the time taken to say 'on your bike'). -- Website: http://hallambaker.com/ --f46d044472bb2da4b404b1e4eb4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Nov 16, 2011 at 2:27 AM, Simon J= osefsson <simon= @josefsson.org> wrote:
Phillip Hallam-Baker <hallam@gmail.com> writes:

> There is no shortage of cryptographic algorithms. I can't see why = TLS
> should even spend the time considering Camellia if there was any doubt=
> about the ability to use it in IPSEC. The only algorithms I can ever s= ee
> being worth consideration at this point would be ones that are suffici= ently
> general purpose that they can be used in multiple protocols.
>
> What I am proposing instead is a low bar to making Camellia an option = in
> any IETF protocol. I believe this to be a Pareto improvement as follow= s:
>
> * The developers of Camellia can get their algorithm enabled as an opt= ion
> in all IETF protocols in a single operation.

The situation with Camellia has another angle to it: the patent
statements about it only applies to specific protocols, and there are
now statements for (at least) TLS and Kerberos. =A0If Camellia is to be
considered for any other protocol, a new patent disclosure is required.
So Camellia is not intended to be a general purpose cipher.

Personally, I find this limiting enough that I believe we should not
waste precious review and process time on it. =A0Time that could be spent on standardizing non-encumbered algorithms.

This seems to me to be an argument for having the decision made at the IET= F level. If there are no IPR issues I don't particularly care whether C= amilla is available for use in IPSEC or not. But if there is an IPR issue t= hen I don't want to see it accepted for IPSEC unless it is available fo= r TLS, S/MIME and everything else.

I do not object to encumbered technology as an absolute= principle but I see no reason to spend one minute of any WG time consideri= ng any encumbered technology that does not offer a clear and exceptionally = compelling advantage over unencumbered alternatives.


In this case there is a very clear disad= vantage to having these negotiations made piecemeal on a WG by WG basis. I = don't want to spend a minute in IPSEC if the result is going to be free= for use in TLS and for future IETF protocols.

The issue would be rather different if we were talking = about a technology that does not have an unencumbered alternative at presen= t. But we have a very good unencumbered alternative to Camilla so why spend= any time on it (including the time taken to say 'on your bike').

--
Website: ht= tp://hallambaker.com/

--f46d044472bb2da4b404b1e4eb4e-- From kathleen.moriarty@emc.com Wed Nov 16 18:21:11 2011 Return-Path: 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 DF6B311E80A6 for ; Wed, 16 Nov 2011 18:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVe2+N6TbZwO for ; Wed, 16 Nov 2011 18:21:11 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4245E11E80A3 for ; Wed, 16 Nov 2011 18:21:10 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id pAH2L9lu026600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Nov 2011 21:21:09 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Wed, 16 Nov 2011 21:21:04 -0500 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id pAH2L396021342 for ; Wed, 16 Nov 2011 21:21:03 -0500 Received: from mx06a.corp.emc.com ([169.254.1.5]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Wed, 16 Nov 2011 21:21:03 -0500 From: To: Date: Wed, 16 Nov 2011 21:21:03 -0500 Thread-Topic: MILE Working Group Summary Thread-Index: AQHMpM+Nz/CNUYv6gEKWTybROqr+6Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Wed, 16 Nov 2011 18:27:06 -0800 Subject: [saag] MILE Working Group Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 02:21:12 -0000 MILE Working Group Summary: The MILE working group met for the first time on Wednesday, November 16, 20= 11 at 3:10 PM. =20 We had a successful meeting, the highlights are as follows: RFC6045-bis and RFC6046-bis will move to working group last call following = this meeting. The documents will be updated to reflect their status as bei= ng adopted by the working group prior to the last call (once -00 documents = can be posted). http://tools.ietf.org/html/draft-moriarty-mile-rfc6045-bis-02 http://tools.ietf.org/html/draft-trammell-mile-rfc6046-bis-01 The working group agreed to combine the template document and IANA XML Regi= stry document into a single draft. The working group voted to adopt the co= mbined document. Documents to be combined into WG draft: "Guidelines for Extensions to IODEF for Managed Incident Lightweight Exchan= ge" http://tools.ietf.org/html/draft-trammell-mile-template "Expert Review for IODEF Extensions in IANA XML Registry" http://tools.ietf.org/html/draft-trammell-mile-iodef-xmlreg The =93IODEF Extension to Support Structured Cybersecurity Information=94 d= raft was adopted as a working group item. The draft issues were discussed,= an updated document will be posted that includes the new name reflecting W= G adoption. http://tools.ietf.org/html/draft-takahashi-mile-sci-02 The GRC Report Exchange document (Generalization of RID to exchange XML doc= uments securely) will go to the list for a consensus call on adoption. =20 https://datatracker.ietf.org/doc/draft-moriarty-mile-grc-exchange/ The =93IODEF Extension, Labeling for data protection, retention, policies, = and regulations=94, requires an update before a WG consensus call takes pla= ce. http://tools.ietf.org/html/draft-goodier-mile-data-markers-00.txt The IODEF Guidance document and Forensics extension have not been posted ye= t (in the charter). Please let me know if you have any questions. Thank you! Kathleen From warren@kumari.net Wed Nov 16 19:12:36 2011 Return-Path: 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 4C46611E80F2 for ; Wed, 16 Nov 2011 19:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.266 X-Spam-Level: X-Spam-Status: No, score=-106.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwyaK3IbdDoU for ; Wed, 16 Nov 2011 19:12:34 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id B468411E80EF for ; Wed, 16 Nov 2011 19:12:34 -0800 (PST) Received: from dhcp-227f.meeting.ietf.org (dhcp-227f.meeting.ietf.org [130.129.34.127]) by vimes.kumari.net (Postfix) with ESMTPSA id D82281B404C7 for ; Wed, 16 Nov 2011 22:12:33 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Nov 2011 11:12:31 +0800 Message-Id: To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [saag] DANE summary. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 03:12:36 -0000 DANE met in the first slot of the first day of the meeting -- in spite = (or because) of this we had a productive meeting :-P We worked though the open issues in the issue tracker, discussed them = and will be providing proposed resolutions and / or text to the list for = consideration. We had an interesting set of discussions on what (if anything) can / = should DANE do in environments where DNSSEC validation is not possible. In a fit of optimism (probably unfounded) we hope to finish the protocol = document (draft-ietf-dane-protocol) in the next month or so, and so we = also discussed what we will work on once we ship this. Since the last meeting we published RFC 6394 - Use Cases and = Requirements for DNS-Based Authentication of Named Entities (DANE)saa= From shanna@juniper.net Wed Nov 16 19:30:17 2011 Return-Path: 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 539F51F0CB2 for ; Wed, 16 Nov 2011 19:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.032 X-Spam-Level: X-Spam-Status: No, score=-106.032 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPqy4aNrCT52 for ; Wed, 16 Nov 2011 19:30:16 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 357341F0CA5 for ; Wed, 16 Nov 2011 19:30:16 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTsR/x/pfYLK+Ma/WI5y70JugHgdFK068@postini.com; Wed, 16 Nov 2011 19:30:16 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 16 Nov 2011 19:25:50 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 16 Nov 2011 22:25:50 -0500 From: Stephen Hanna To: "saag@ietf.org" Date: Wed, 16 Nov 2011 22:25:48 -0500 Thread-Topic: NEA report Thread-Index: Acyk2Jl6IbGU3f9bTkOrgwL/ezLwVw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [saag] NEA report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 03:30:17 -0000 NEA met on Thursday at 0900. We have two active WG documents: PT-EAP and PT-TLS. We discussed a bunch of comments on both documents, most from the list and a few received at the meeting. Many were uncontroversial simplifications. For the trickier issues, we got volunteers to study them and come up with proposed resolutions. And we got two more volunteers to review PT-EAP. We agreed to bring draft-salowey-nea-asokan-00.txt (the NEA Asokan Attack Analysis) in as a WG draft since both PT specs refer to it and advance it to Informational. We may expand that document to cover Asokan attacks in general, if that's not too hard. But having any RFC on Asokan attacks will be a good way to raise awareness. From tlyu@mit.edu Wed Nov 16 20:01:45 2011 Return-Path: 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 E7FED1F0CBB for ; Wed, 16 Nov 2011 20:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SB5RkL3Tyxc for ; Wed, 16 Nov 2011 20:01:45 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4741F0C70 for ; Wed, 16 Nov 2011 20:01:45 -0800 (PST) X-AuditID: 12074425-b7f116d0000008fe-b3-4ec4872813ea Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 0F.8B.02302.82784CE4; Wed, 16 Nov 2011 23:01:44 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id pAH41hL9032678; Wed, 16 Nov 2011 23:01:43 -0500 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pAH41eJp025720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Nov 2011 23:01:41 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id pAH41ene010646; Wed, 16 Nov 2011 23:01:40 -0500 (EST) To: David McGrew References: From: Tom Yu Date: Wed, 16 Nov 2011 23:01:40 -0500 In-Reply-To: (David McGrew's message of "Wed, 16 Nov 2011 07:04:34 -0800") Message-ID: Lines: 27 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IRYrdT19VoP+Jn8O+KusXV5ceZLK6u+sNu ceraETaLKf2dTA4sHlN+b2T1eHnqHKPHzll32T2WLPnJFMASxWWTkpqTWZZapG+XwJVxc/1t xoJTvBWPv/ewNTA2c3cxcnJICJhIzJz6mxHCFpO4cG89G4gtJLCPUeLkP5kuRi4gewOjRFfT S1YI5wqTRPOjqYwQVV2MEkfucoDYIgLKElvfTWcCsZkFsiRmXm9mB7GFBRwlZhydxgbRfIpR 4unMx8xdjBwcbALSEkcXl4HUsAioSkzZ8J8VxOYUqJZ4PPEq2HxeAQuJJ++Pgs3hEeCUeLOh ByouKHFy5hMWiF1aEjf+vWSawCg4C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRboW ermZJXqpKaWbGMEB7aK6g3HCIaVDjAIcjEo8vDdYj/gJsSaWFVfmHmKU5GBSEuV93AwU4kvK T6nMSCzOiC8qzUktPsQowcGsJMLbfOewnxBvSmJlVWpRPkxKmoNFSZz39Q4HPyGB9MSS1OzU 1ILUIpisOgeHwJX9v8KlWPLy81KVJHjr2oDmCxalpqdWpGXmlCBUMnFwguzhAdpTDVLDW1yQ mFucmQ6RP8WoKCXO+7gBKCEAksgozYPrhaWhV4ziQF8J8wo3AlXxAFMYXPcroMFMQIPXHjwA MrgkESEl1cDocjTw5MK0GUZtl85WZwh9XLczgGF92TXfiSLyUjqrlx4VuXWzNjtPyFz32Zkl VxmmvzZiv+TNFyuW9FX476ZnG4OWmXZwWmTZz3786AC/nvLC+ruV7oa3J+TuLfzxRr5ywhYZ c+6ec74+L6dekJk61/nyrf87/Uxnt+2sn/lA/5wDx6wCw8fOSizFGYmGWsxFxYkA6RrO3h4D AAA= Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 04:01:46 -0000 David McGrew writes: > There may be a role for a "global" decision here. The only important > technical argument for recommending the implementation of more than > one cipher is to provide for security through algorithm diversity. It > might make sense to select an alternate cipher to the AES to act as a > standby in case of unanticipated future advances in cryptanalysis. If > we do this, it would be best to select a single algorithm, which could > have a status on Phillip's list somewhere below MUST-implement but > above MAY-implement. Any process used for the selection of a standby > should meet the same stringent criteria for extensive public review > and analysis as the AES did, and should meet all of the criteria set > out for the AES: security, computational efficiency, memory > requirements, hardware and software suitability, simplicity, > flexibility, and licensing requirements. In particular, it should be > available worldwide on a royalty-free basis. Since the major goal of > a standby cipher is to be secure even if the AES proves vulnerable to > future advances in cryptanalysis, the standby algorithm should not > follow a design strategy that is identical to that of the AES. Or > perhaps a better way to state the last requirement is: a standby > algorithm should have a sound technical argument why it would survive > advances in cryptanalysis that would be damaging to the AES. Are you proposing that the IETF (or CFRG) undertake an evaluation effort of the same magnitude as the NIST AES competition? That sounds expensive and time-consuming. Would it be useful to instead look at other cipher evaluation efforts, such as the EU's NESSIE project? From tlyu@mit.edu Wed Nov 16 21:05:55 2011 Return-Path: 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 63F0A1F0CA1 for ; Wed, 16 Nov 2011 21:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehD4OFWcaQpI for ; Wed, 16 Nov 2011 21:05:50 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 220FF1F0C42 for ; Wed, 16 Nov 2011 21:05:50 -0800 (PST) X-AuditID: 12074424-b7ef76d0000008dc-c1-4ec4962dec13 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 26.C1.02268.D2694CE4; Thu, 17 Nov 2011 00:05:49 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id pAH55m1E013768; Thu, 17 Nov 2011 00:05:48 -0500 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pAH55g68002841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Nov 2011 00:05:45 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id pAH55gQ8011024; Thu, 17 Nov 2011 00:05:42 -0500 (EST) To: David McGrew References: <87sjlo4je3.fsf@latte.josefsson.org> From: Tom Yu Date: Thu, 17 Nov 2011 00:05:41 -0500 In-Reply-To: (David McGrew's message of "Wed, 16 Nov 2011 06:05:19 -0800") Message-ID: Lines: 35 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT0dWddsTPYNJ3SYury48zWVxd9Yfd Ykp/J5PFvS2X2B1YPKb83sjqsXPWXXaPJUt+MnnMPHORPYAlissmJTUnsyy1SN8ugStj9YTL TAUXeSoO7tnG0sB4hKuLkZNDQsBE4sW8uSwQtpjEhXvr2boYuTiEBPYxSvTvv80K4WxglDi0 5zMzhHOFSWLO7HVQThejxMan2xhB+kUElCW2vpvOBGIzC2RJPL14EywuLOAoMePoNKi5O5gk bp3+yt7FyMHBJiAtcXRxGUgNi4CqxLTDz9lAbE6Baomp72eAzeEVsJB4NGsCM4jNI8Ap0bei nwUiLihxcuYTFohdWhI3/r1kmsAoOAtJahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW6 5nq5mSV6qSmlmxjBQe2isoOx+ZDSIUYBDkYlHt4m5iN+QqyJZcWVuYcYJTmYlER5haYAhfiS 8lMqMxKLM+KLSnNSiw8xSnAwK4nwNt857CfEm5JYWZValA+TkuZgURLntdnp4CckkJ5Ykpqd mlqQWgSTVefgELiy/1e4FEtefl6qkgTvvqlA8wWLUtNTK9Iyc0oQKpk4OEH28ADt+dAFVMNb XJCYW5yZDpE/xagoJc47EaRZACSRUZoH1wtLRa8YxYG+EuZ1AaniAaYxuO5XQIOZgAavPXgA ZHBJIkJKqoFxib/NWd4ZK5nsfs6xProjubNqgm4E96EbzUe/fSrIa13MU/ifld2qZfOubvfH 1s1a9qfmHylvatl8VXifb28XD2vBZObPMz/8jX9w1nyKV4721h8nGx6IXtl7Lbh4yZv/aes+ cizse3Ju++uGsiuNHksWrrK4J1NUJdn0il/Q7MPHGuYpM9dMVWIpzkg01GIuKk4EAKXHwBwg AwAA Cc: Simon Josefsson , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 05:05:55 -0000 David McGrew writes: > Agreed. Any algorithm that seeks broad acceptance needs to be > available royalty-free around the world. There is an available pool > of such ciphers that were created during the AES process (serpent, > twofish, ...) plus some other more modern IPR-free ciphers that could > be used to achieve algorithm diversity in standards. The IETF needs > to be clear and firm in not mandating the implementation of patent- > encumbered ciphers. > > David > > > [1] "Announcement of Royalty-free Licenses for Essential Patents of > NTT Encryption and Digital Signature Algorithms" > > > > [2] NTT-Mitsubishi Patent Licensing Statment for Camellia > 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 885C111E816D for ; Thu, 17 Nov 2011 00:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.836 X-Spam-Level: X-Spam-Status: No, score=-102.836 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxKPHHJo6U3T for ; Thu, 17 Nov 2011 00:20:07 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A4B5611E8172 for ; Thu, 17 Nov 2011 00:20:07 -0800 (PST) Received: by ywt34 with SMTP id 34so850613ywt.31 for ; Thu, 17 Nov 2011 00:20:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=Q7rj5C8kNyq07U+NIy+CrG+6/k5nDDL5A2AusxYyXkg=; b=mwdj919VyStvNMXwf9wVtW+DJvfWBUO3bOkL4DKM84fwfvNO9svVblg/xC5q6ynVgz gBI5prJEQoKHRsgWDcv2e3zKejlXTBDgYaAhkzSpPiK2fSgycqNOLqv15vHl3woPQaOA qBJwFvYVnP8nMSeGSR+orU5a36rOh+eyWdF24= MIME-Version: 1.0 Received: by 10.236.22.4 with SMTP id s4mr1554715yhs.8.1321518005363; Thu, 17 Nov 2011 00:20:05 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.236.203.196 with HTTP; Thu, 17 Nov 2011 00:20:05 -0800 (PST) Date: Thu, 17 Nov 2011 16:20:05 +0800 X-Google-Sender-Auth: MdZNr4YSN1JFewu2Kp712YMd0Yk Message-ID: From: Barry Leiba To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [saag] OAuth summary from IETF 82 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 08:20:08 -0000 It's probably easiest to do this with an annotated agenda: 1. Agenda Bashing, and WG Status Base doc: TLS version issue has consensus, check on the list (Barry will post). Otherwise, the doc needs a new revision from AD comments. Bearer: long discussion about mandatory-to-implement token type. Stephen is very firm on the need for it, for interoperability. Consensus in the room favors having one, and for it to be bearer token. This is an update to the base protocol doc. Confirm on the list. Both documents will go into IETF last call together, when the new versions are ready. 1a. Bearer Token: Encoding Problems Remote presentation by Julian Reschke Julian presents HTTP issues with some bearer-token fields. The fields in question are protocol elements, not human-readable strings, and need no internationalization. If the fields are limited to ASCII, the problem goes away. This is acceptable to Mike and to Julian. 2. Status and issues with existing documents: 2a. HTTP Authentication: MAC Access Authentication http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac Little interest shown for this document so far. Chairs want a co-editor to help edit and to push reviews. 2b. Assertions http://tools.ietf.org/html/draft-ietf-oauth-assertions http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer Status: updated, need more reviews; Jeff Hodges recruited. Still want others; Hannes will follow up. 2c. OAuth 2.0 Threat Model and Security Considerations http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel In WGLC immediately, ending on 9 Dec. 3. Rechartering discussion A few presentations about some of the proposed items. See the meeting materials page: https://datatracker.ietf.org/meeting/82/materials.html Discussion of some priority items: - JSON web token format, and bearer profile - Client registration - Token revocation - Simple web discovery Discussion and prioritization will continue on the list. Barry and Hannes, OAuth chairs From stephen.farrell@cs.tcd.ie Thu Nov 17 01:09:55 2011 Return-Path: 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 DBEC421F9B38 for ; Thu, 17 Nov 2011 01:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIkAEoa80qWq for ; Thu, 17 Nov 2011 01:09:51 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 5801921F99F8 for ; Thu, 17 Nov 2011 01:09:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 2E163171CCB; Thu, 17 Nov 2011 09:09:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1321520984; bh=NECjTqcfLYId9laZZ9qdVtax jtVHF844fB4CRZHl8V8=; b=saH9YyCb8qtxoB8sVNTbkp3OhzM7YTEqk7y/iWW4 SvZdtZFIjHCiDpzS7CYPr/r80/T+TlUYZcYrE2QyEybHPQotkg59VSJWhPzfzeYM TKHIlNXUVtox7wgmnmsQUO30lo4IuahGfkzEyHnWwWZobsWCZLr9OYpX6AGdIR71 UF+1P4aogFg3ubeSS3ELIt3u3eBtJMHgHC4nDD2spkm+rpALDjJaY4NBOmER5TMZ x1KBEtWMmcASfQKcekPchu57dxKpjZLEUxl1olNiVuoCe1SoOS1KQJMkch5yhf/i SY4Mq2ZAPJ89+mlRv3FRDLGDF9m0V8HxUYl9y8jFFiDeaw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id VgiGM6JGRwFW; Thu, 17 Nov 2011 09:09:44 +0000 (GMT) Received: from [130.129.37.121] (dhcp-2579.meeting.ietf.org [130.129.37.121]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2A565171BFD; Thu, 17 Nov 2011 09:09:41 +0000 (GMT) Message-ID: <4EC4CF52.5030401@cs.tcd.ie> Date: Thu, 17 Nov 2011 09:09:38 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "saag@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Colin Perkins , Robert Sparks Subject: [saag] vbr srtp question X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 09:09:56 -0000 Hi, We had a presentation [1] at the saag session today about some recommendations [2] for safely using variable bit rate encoding and SRTP. Robert correctly pointed out that I didn't state the specific concern that I had with the document, and for which I'm looking for a bit of help. The issue is that a recent paper [3] might (or might not) imply that the recommendations in the draft should be strengthened or changed. My problem is that I don't really know whether or not some change is actually needed (since I've not had time and probably just don't know enough;-) If someone can offer specific help on this aspect in the next week or two please let me know. Thanks, Stephen. [1] http://www.ietf.org/proceedings/82/slides/saag-1.pdf [2] https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-vbr-audio/ [3] White, A.M.; Matthews, A.R.; Snow, K.Z.; Monrose, F.; , "Phonotactic Reconstruction of Encrypted VoIP Conversations: Hookt on Fon-iks," Security and Privacy (SP), 2011 IEEE Symposium on , vol., no., pp.3-18, 22-25 May 2011 doi: 10.1109/SP.2011.34 URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5958018&isnumber=5958008 From simon@josefsson.org Thu Nov 17 01:51:53 2011 Return-Path: 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 DB33221F9B77 for ; Thu, 17 Nov 2011 01:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.811 X-Spam-Level: X-Spam-Status: No, score=-101.811 tagged_above=-999 required=5 tests=[AWL=-1.902, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zZBiI4Msfua for ; Thu, 17 Nov 2011 01:51:47 -0800 (PST) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7468521F9B75 for ; Thu, 17 Nov 2011 01:51:47 -0800 (PST) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id pAH9oPsP025166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 17 Nov 2011 10:50:26 +0100 From: Simon Josefsson To: Tom Yu References: <87sjlo4je3.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:111117:saag@ietf.org::vW8mPG30gPqW4Khu:00e1 X-Hashcash: 1:22:111117:mcgrew@cisco.com::GundZ9hBmWH9xJ3n:Y1eL X-Hashcash: 1:22:111117:tlyu@mit.edu::Kiq8d22fo+ZYl6Lj:PWSX X-Hashcash: 1:22:111117:hallam@gmail.com::vKpO0d214L/6uWoY:08w0R Date: Thu, 17 Nov 2011 10:50:25 +0100 In-Reply-To: (Tom Yu's message of "Thu, 17 Nov 2011 00:05:41 -0500") Message-ID: <87zkfvm61q.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 09:51:54 -0000 Tom Yu writes: > David McGrew writes: > >> Agreed. Any algorithm that seeks broad acceptance needs to be >> available royalty-free around the world. There is an available pool >> of such ciphers that were created during the AES process (serpent, >> twofish, ...) plus some other more modern IPR-free ciphers that could >> be used to achieve algorithm diversity in standards. The IETF needs >> to be clear and firm in not mandating the implementation of patent- >> encumbered ciphers. >> >> David >> >> >> [1] "Announcement of Royalty-free Licenses for Essential Patents of >> NTT Encryption and Digital Signature Algorithms" >> >> >> >> [2] NTT-Mitsubishi Patent Licensing Statment for Camellia >> > Quoting from http://www.ntt.co.jp/news/news06e/0604/060413a.html > > "Hereafter, however, in accordance with an agreement between NTT and > Mitsubishi, Camellia essential patents can be used at no charge by any > Camellia user without concluding such royalty-free licensing agreement > hereafter. > Of course, if there is your request, patent execution consent from NTT > and Mitsubishi based on the royalty-free licensing agreement for > essential patents can be obtained in the same way as up to now." > > I am not a lawyer, but I read that as declaring that they won't > enforce the Camellia patents, but will provide formal royalty-free > licenses if desired. However, that's somewhat in conflict with the > wording of their IPR statements, which say things about reciprocity. And other things, including restricting the license to a particular protocol. A 5 year old press release has little weight compared to the patent disclosures filed with the IETF, in my opinion. /Simon From simon@josefsson.org Thu Nov 17 01:58:53 2011 Return-Path: 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 0F57721F9B3B for ; Thu, 17 Nov 2011 01:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.621 X-Spam-Level: X-Spam-Status: No, score=-101.621 tagged_above=-999 required=5 tests=[AWL=-1.712, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rupOKcO82mT for ; Thu, 17 Nov 2011 01:58:52 -0800 (PST) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3B30821F9B3A for ; Thu, 17 Nov 2011 01:58:52 -0800 (PST) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id pAH9wiWY025267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 17 Nov 2011 10:58:45 +0100 From: Simon Josefsson To: Satoru Kanno References: <87sjlo4je3.fsf@latte.josefsson.org> <4EC44D40.1000703@po.ntts.co.jp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:111117:kanno.satoru@po.ntts.co.jp::3l47xd3jI29oFv4P:Tzp X-Hashcash: 1:22:111117:saag@ietf.org::ibahv76pFX//BDA+:MgYa X-Hashcash: 1:22:111117:hallam@gmail.com::+f31DzDvxZVzgjbs:zV7h Date: Thu, 17 Nov 2011 10:58:44 +0100 In-Reply-To: <4EC44D40.1000703@po.ntts.co.jp> (Satoru Kanno's message of "Thu, 17 Nov 2011 08:54:40 +0900") Message-ID: <87vcqjm5nv.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 09:58:53 -0000 Satoru Kanno writes: > Hi Simon and Phillip, > > (2011/11/16 16:27), Simon Josefsson wrote: >> Phillip Hallam-Baker writes: >> >>> There is no shortage of cryptographic algorithms. I can't see why TLS >>> should even spend the time considering Camellia if there was any doubt >>> about the ability to use it in IPSEC. The only algorithms I can ever see >>> being worth consideration at this point would be ones that are sufficiently >>> general purpose that they can be used in multiple protocols. >>> >>> What I am proposing instead is a low bar to making Camellia an option in >>> any IETF protocol. I believe this to be a Pareto improvement as follows: >>> >>> * The developers of Camellia can get their algorithm enabled as an option >>> in all IETF protocols in a single operation. >> >> The situation with Camellia has another angle to it: the patent >> statements about it only applies to specific protocols, and there are >> now statements for (at least) TLS and Kerberos. If Camellia is to be >> considered for any other protocol, a new patent disclosure is required. >> So Camellia is not intended to be a general purpose cipher. >> > > Up to now, because we proposed adding the Camellia cipher to each > protocols, we filed the Camellia IPRs for the relevant WGs. > > If IETF changes the policy of addition of cipher algorithms to new > one, of course, NTT & Mitsubishi intend to file for the revised > general-purpose IPR which permits to use Camellia cipher in any > protocols in IETF. I do not believe the IETF has changed any policy in this area. The essential policies are described in RFC 3979 [1]. You could file a general patent disclosure on Camellia instead of a specific disclosure for each and every draft. Generally, you are at liberty to use any license you want for your patent, but the community is at liberty to ignore your work if the license is considered to "get in the way". I for one would welcome a new general patent disclosures that says you permit use of Camellia for any purpose to everyone. /Simon [1] https://www.ietf.org/rfc/rfc3979.txt From mcgrew@cisco.com Thu Nov 17 07:29:44 2011 Return-Path: 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 F0B0421F99C2 for ; Thu, 17 Nov 2011 07:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.441 X-Spam-Level: X-Spam-Status: No, score=-106.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCRBvNPopiLC for ; Thu, 17 Nov 2011 07:29:44 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 66FED21F99C1 for ; Thu, 17 Nov 2011 07:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=3546; q=dns/txt; s=iport; t=1321543784; x=1322753384; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=YJ9YriUSe2b3b5kGT427uSExoUPNpeMkwmwcSexRNZc=; b=IlPsn/biIjSd26atEi6M/2ynDZiUUPvLOmOwosw5eWFK7KPJ7hvso7kr KQWbv3KURDZCgIA8pwpZoM5Tbo2+XOHy7m6zmjTxProk17kdoR9oqxnjI 405bqKivzRVlmDengCuS8cHyzSV7PKjliFih/yATBnQJaChOvzIC2cqwq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAI8nxU6rRDoI/2dsb2JhbABCDqcngneBBYFyAQEBAwESASUCMQ4FCwsOOFcGEyKHYAiXPQGeTYk0YwSIFYwghTuMClg X-IronPort-AV: E=Sophos;i="4.69,527,1315180800"; d="scan'208";a="14782720" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 17 Nov 2011 15:29:44 +0000 Received: from [10.32.254.210] ([10.32.254.210]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAHFThP2023929; Thu, 17 Nov 2011 15:29:43 GMT Message-Id: <7EE381E6-0A2E-428F-BCD3-E6B09ACE9304@cisco.com> From: David McGrew To: Tom Yu In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 17 Nov 2011 07:29:42 -0800 References: X-Mailer: Apple Mail (2.936) Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 15:29:45 -0000 Hi Tom, On Nov 16, 2011, at 8:01 PM, Tom Yu wrote: > David McGrew writes: > >> There may be a role for a "global" decision here. The only important >> technical argument for recommending the implementation of more than >> one cipher is to provide for security through algorithm diversity. >> It >> might make sense to select an alternate cipher to the AES to act as a >> standby in case of unanticipated future advances in cryptanalysis. >> If >> we do this, it would be best to select a single algorithm, which >> could >> have a status on Phillip's list somewhere below MUST-implement but >> above MAY-implement. Any process used for the selection of a >> standby >> should meet the same stringent criteria for extensive public review >> and analysis as the AES did, and should meet all of the criteria set >> out for the AES: security, computational efficiency, memory >> requirements, hardware and software suitability, simplicity, >> flexibility, and licensing requirements. In particular, it should be >> available worldwide on a royalty-free basis. Since the major goal of >> a standby cipher is to be secure even if the AES proves vulnerable to >> future advances in cryptanalysis, the standby algorithm should not >> follow a design strategy that is identical to that of the AES. Or >> perhaps a better way to state the last requirement is: a standby >> algorithm should have a sound technical argument why it would survive >> advances in cryptanalysis that would be damaging to the AES. > > Are you proposing that the IETF (or CFRG) undertake an evaluation > effort of the same magnitude as the NIST AES competition? That sounds > expensive and time-consuming. Would it be useful to instead look at > other > cipher evaluation efforts, such as the EU's NESSIE project? good questions. I'm not proposing that IETF or IRTF manage a cipher competition. As you say, it would be a considerable effort; besides, neither of those groups has the needed quorum of expertise. But I do see an important role for the IETF in setting requirements and priorities. Perhaps a good way to do this would be to draft up requirements in a format that would be useful input to cipher evaluation projects like ECRYPT and CRYPTREC. This could be very positive for the Internet, if it helps to channel the pressure for alternative ciphers into a useful direction. The flip side of this is: within IETF, we should not uncritically accept the assertion that a particular cipher should be adopted by a particular protocol because it could be useful as a standby cipher. An aside: there has been a good amount of discussion about alternative block ciphers, because of Camellia, SEED, ARIA, and GOST. There ought to be more consideration to other technical aspects, such as the way the block cipher is used. For instance, all of the modes in current standards use b invocations of the block cipher to encrypt b blocks of data. There are modes of operation that achieve quantifiably higher security levels by using more block cipher invocations (the most practical example being Iwata's CENC mode [1] which uses one additional invocation). It is fair to ask: if our goal is to make standards that are impervious to future advances in cryptanalysis, would it be better to adopt a different mode instead of a different block cipher? David [1] From nico@cryptonector.com Thu Nov 17 10:56:28 2011 Return-Path: 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 CC20721F9965 for ; Thu, 17 Nov 2011 10:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JY+4YOx1tjsd for ; Thu, 17 Nov 2011 10:56:28 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2E05021F9962 for ; Thu, 17 Nov 2011 10:56:28 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id D728288072 for ; Thu, 17 Nov 2011 10:56:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=p03OxX33ntgv92Le2RUHSGo87vAp8FpbxQ8jbKzTEcSh tTCSgO+rAagPaldqn3BekN9qMz/ZCUYl/GTtprnKe9hfFhGaHDTWbDnwPfEKEIcY KT+jQ1WS9ZfzPHzqCGeUX8hpabfGJZ+xGBfKpjfY9AjxDQJsDhyJt6fLCC4HNVg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=W9sOob82quSea/L3Q2NIrga+CNk=; b=s5XQFKm5juS aUTkksl5g9qUz1hzRNL1cOglS8BHlOOjvrukf67lGp3bJb3jNYXFO2nbt9qjtFjo rZDzk0mk8lPEsvlnzc3Xb6+f57UMLJzqiNGtZd0wLEVUUVZnmlo6j2DgIRA7md+7 qFHazsRcoEd6SGWOY/B6Azz2EquIHxV4= Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id 83BE28806D for ; Thu, 17 Nov 2011 10:56:27 -0800 (PST) Received: by wwe5 with SMTP id 5so3035375wwe.13 for ; Thu, 17 Nov 2011 10:56:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.25.170 with SMTP id d10mr1358823pbg.7.1321556185063; Thu, 17 Nov 2011 10:56:25 -0800 (PST) Received: by 10.68.192.70 with HTTP; Thu, 17 Nov 2011 10:56:24 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Nov 2011 12:56:24 -0600 Message-ID: From: Nico Williams To: David McGrew Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 18:56:28 -0000 On Wed, Nov 16, 2011 at 9:04 AM, David McGrew wrote: > On Nov 15, 2011, at 10:06 AM, Nico Williams wrote: >> It might make sense to limit this new registry to just a few protocols >> (PKIX, TLS, CMS, leaving out Kerberos, SSH?), then add the remaining >> protocols as we gain experience with the new registry. =C2=A0But even so= , I >> think we want some idea of what the registry and registration process >> will look like when we're done. > > That's a practical suggestion. Yes, but my unstated aim was to show that Philip's proposed registry would be rather complex, complex enough that we'd have to choose to either make it incomplete or informative. I don't see enough value in having a complete and normative registry of crypto algorithms for Internet protocols to bother with the complexity of such a registry. There, I've said it :) >> [...] > > I think that what you mean could be said as: the crypto algorithm should = be > responsible for the IV or nonce, and not the protocol. =C2=A0I think that= 's a > great idea. That's not what I had in mind, but it's important to clarify this now that you mention it. The protocol must be responsible for all parameters of a cryptographic algorithm that the algorithm exposes. Confounders and nonce IVs for CBC mode ciphers, for example, are NOT / should NOT be exposed parameters of the cipher in any mode that has such things (certainly not in Kerberos), thus the application protocol cannot be responsible for them. But keys and AEAD message IVs *are* exposed parameters of the cipher, and must be supplied by the application protocol. In any PSK protocol we must be extremely careful about selection of AEAD message IVs, as IV repetition has extremely negative impact on the security of the protocol. ASIDE: the typical AEAD IV size (between 96- and 128-bit) is too small for comfort for PSK, enough that I'd propose using additional bits for deriving message keys, thus yielding an effective message IV of 256 bits -- enough to greatly reduce chances of accidental IV reuse, to the point where I'd feel comfortable. (Kerberos effectively uses PSK, so this applies to Kerberos.) >> However, though we have lots of deja vu moments today in each >> protocol/WG, we do benefit from being able to make different MTI >> decisions in each case (i.e., implementors for each protocol are only >> affected by consensus for that protocol, not global consensus). > > There may be a role for a "global" decision here. =C2=A0The only importan= t > [...] Maybe, but I think that matter is entirely separable from the proposal for a common crypto algorithm protocol specification registry. Nico -- From mcgrew@cisco.com Thu Nov 17 11:14:53 2011 Return-Path: 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 A4B6E21F9464 for ; Thu, 17 Nov 2011 11:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhVXy6rT92C1 for ; Thu, 17 Nov 2011 11:14:53 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 27EFA21F93B3 for ; Thu, 17 Nov 2011 11:14:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2995; q=dns/txt; s=iport; t=1321557293; x=1322766893; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=oSNozG7eaxKgaVfBpBwyd7GR0/H+n0N4OIjZI0x0bo4=; b=BYa9RdVkYYpqeQfQodmeTdFY1ldxeNGrMEq0lWSC8GFlsut+kW1tWL43 jpvIhrfxXAo+wAzsYL4uCtDhX3tlHlNfhJ5YAeJllOIFl2VKmD+07LlhE MEJZcAv5BpWArYwplxuozQl8WOf9Ti28976ZIudJ5Nf8QJnvJrOWsjzEu 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJxcxU6rRDoI/2dsb2JhbABCqi2BBYFyAQEBAwESASUCMgoDBQsLGC5XBhMih2CXYQGeQYk0YwSIFYwghTuMYg X-IronPort-AV: E=Sophos;i="4.69,528,1315180800"; d="scan'208";a="13132084" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 17 Nov 2011 19:14:52 +0000 Received: from [10.32.254.210] ([10.32.254.210]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAHJEpIv015185; Thu, 17 Nov 2011 19:14:52 GMT Message-Id: <6F5C3122-53C5-4C76-A33D-36D5A27261C8@cisco.com> From: David McGrew To: Nico Williams In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 17 Nov 2011 11:14:51 -0800 References: X-Mailer: Apple Mail (2.936) Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 19:14:53 -0000 Hi Nico, On Nov 17, 2011, at 10:56 AM, Nico Williams wrote: > On Wed, Nov 16, 2011 at 9:04 AM, David McGrew > wrote: >> On Nov 15, 2011, at 10:06 AM, Nico Williams wrote: >>> It might make sense to limit this new registry to just a few >>> protocols >>> (PKIX, TLS, CMS, leaving out Kerberos, SSH?), then add the remaining >>> protocols as we gain experience with the new registry. But even >>> so, I >>> think we want some idea of what the registry and registration >>> process >>> will look like when we're done. >> >> That's a practical suggestion. > > Yes, but my unstated aim was to show that Philip's proposed registry > would be rather complex, complex enough that we'd have to choose to > either make it incomplete or informative. I don't see enough value in > having a complete and normative registry of crypto algorithms for > Internet protocols to bother with the complexity of such a registry. > There, I've said it :) :-) > >>> [...] >> >> I think that what you mean could be said as: the crypto algorithm >> should be >> responsible for the IV or nonce, and not the protocol. I think >> that's a >> great idea. > > That's not what I had in mind, but it's important to clarify this now > that you mention it. The protocol must be responsible for all > parameters of a cryptographic algorithm that the algorithm exposes. > Confounders and nonce IVs for CBC mode ciphers, for example, are NOT / > should NOT be exposed parameters of the cipher in any mode that has > such things (certainly not in Kerberos), thus the application protocol > cannot be responsible for them. But keys and AEAD message IVs *are* > exposed parameters of the cipher, and must be supplied by the > application protocol. > > In any PSK protocol we must be extremely careful about selection of > AEAD message IVs, as IV repetition has extremely negative impact on > the security of the protocol. ASIDE: the typical AEAD IV size > (between 96- and 128-bit) is too small for comfort for PSK, enough > that I'd propose using additional bits for deriving message keys, thus > yielding an effective message IV of 256 bits -- enough to greatly > reduce chances of accidental IV reuse, to the point where I'd feel > comfortable. (Kerberos effectively uses PSK, so this applies to > Kerberos.) > As an aside, GCM and SIV modes can use arbitrary-length IVs. >>> However, though we have lots of deja vu moments today in each >>> protocol/WG, we do benefit from being able to make different MTI >>> decisions in each case (i.e., implementors for each protocol are >>> only >>> affected by consensus for that protocol, not global consensus). >> >> There may be a role for a "global" decision here. The only important >> [...] > > Maybe, but I think that matter is entirely separable from the proposal > for a common crypto algorithm protocol specification registry. Agreed. David > > Nico > -- From nico@cryptonector.com Thu Nov 17 11:26:18 2011 Return-Path: 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 E800C21F9772 for ; Thu, 17 Nov 2011 11:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjEfPxSGBw6Y for ; Thu, 17 Nov 2011 11:26:18 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id F1F1D21F9771 for ; Thu, 17 Nov 2011 11:26:17 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 872C567C06E for ; Thu, 17 Nov 2011 11:26:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=bhbAwwiYYFPMNFLTr403vsNfQWfgnIB4Jr3GPB6djyxr M8oqu8q4OCtpRdSp8e/xdb8NmClGc3kccCZZ6q92nX0Ke8FwLF+aHs7Ub/9gssGE 6hugNjI6V4nfyr46/ERw/L2ev9TvnYp15tVy8QdW5nw4cYHRpW4Rr14Ce54R8pQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=FFOt1RqUQIUHKP5I1O/bo6j8uUE=; b=d/0rWCyIe/0 LeTGo1p6vDT5TKNl3RtyP2xjS5LJ7GK4IpHty8sGpU50nhBuVKmN+4EicBsay+OR jphBSgj8wz+kkfxIfPIny7SsQjKVqmzB/RdUGQkTP2VZqn9ar2Orbsk4jmsLVYAH JHzIkyWfi/E+g+lFZQQZXVFrQ7NqiSRY= Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 261FB67C06D for ; Thu, 17 Nov 2011 11:26:16 -0800 (PST) Received: by wyf28 with SMTP id 28so2838620wyf.31 for ; Thu, 17 Nov 2011 11:26:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.44.40 with SMTP id b8mr1565563pbm.41.1321557974804; Thu, 17 Nov 2011 11:26:14 -0800 (PST) Received: by 10.68.192.70 with HTTP; Thu, 17 Nov 2011 11:26:14 -0800 (PST) In-Reply-To: <6F5C3122-53C5-4C76-A33D-36D5A27261C8@cisco.com> References: <6F5C3122-53C5-4C76-A33D-36D5A27261C8@cisco.com> Date: Thu, 17 Nov 2011 13:26:14 -0600 Message-ID: From: Nico Williams To: David McGrew Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 19:26:19 -0000 On Thu, Nov 17, 2011 at 1:14 PM, David McGrew wrote: > On Nov 17, 2011, at 10:56 AM, Nico Williams wrote: >> In any PSK protocol we must be extremely careful about selection of >> AEAD message IVs, as IV repetition has extremely negative impact on >> the security of the protocol. =C2=A0ASIDE: the typical AEAD IV size >> (between 96- and 128-bit) is too small for comfort for PSK, enough >> that I'd propose using additional bits for deriving message keys, thus >> yielding an effective message IV of 256 bits -- enough to greatly >> reduce chances of accidental IV reuse, to the point where I'd feel >> comfortable. =C2=A0(Kerberos effectively uses PSK, so this applies to >> Kerberos.) > > As an aside, GCM and SIV modes can use arbitrary-length IVs. But it's effectively MACed down to 96-bits. I suppose that makes it difficult enough to tell when there's been reuse of the effective 96-bits that it's secure. I'll think about that. Nico -- From mcgrew@cisco.com Thu Nov 17 12:25:06 2011 Return-Path: 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 1E4A611E80D0 for ; Thu, 17 Nov 2011 12:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.456 X-Spam-Level: X-Spam-Status: No, score=-106.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyWOqLwscnZ4 for ; Thu, 17 Nov 2011 12:25:05 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A825F11E80CD for ; Thu, 17 Nov 2011 12:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=1315; q=dns/txt; s=iport; t=1321561505; x=1322771105; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=TaaL4GQOaXAgE8lS8du6Nj/6d10MeyyYjetYZW7s3Cc=; b=W06B4cvJe+vl0t0dSeziuh9zfEzv1CtyO/VHlGLDozKCtNHQqEDwahy2 K8Bv35SWIoFZHqmMKHnO5X6jBkX+NYi1wLgWZsB5g5TNwHguQX5xYjI/M lD98Y+7g57sKa8m1WIw7O5ChjGaYP1bosaZGNQdVGRS+h8f2P0q99np70 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJZsxU6rRDoH/2dsb2JhbABCqi+BBYFyAQEBAwESASUCPwULCxguVwYTIodgl3YBnjuJNGMEiBWMIIU7jGI X-IronPort-AV: E=Sophos;i="4.69,529,1315180800"; d="scan'208";a="14859824" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 17 Nov 2011 20:25:05 +0000 Received: from [10.32.254.210] ([10.32.254.210]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAHKP4ga005794; Thu, 17 Nov 2011 20:25:04 GMT Message-Id: <7F7F8624-48EB-4E1D-8160-84DADA4673EB@cisco.com> From: David McGrew To: Nico Williams In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 17 Nov 2011 12:25:03 -0800 References: <6F5C3122-53C5-4C76-A33D-36D5A27261C8@cisco.com> X-Mailer: Apple Mail (2.936) Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 20:25:06 -0000 Hi Nico, On Nov 17, 2011, at 11:26 AM, Nico Williams wrote: > On Thu, Nov 17, 2011 at 1:14 PM, David McGrew > wrote: >> On Nov 17, 2011, at 10:56 AM, Nico Williams wrote: >>> In any PSK protocol we must be extremely careful about selection of >>> AEAD message IVs, as IV repetition has extremely negative impact on >>> the security of the protocol. ASIDE: the typical AEAD IV size >>> (between 96- and 128-bit) is too small for comfort for PSK, enough >>> that I'd propose using additional bits for deriving message keys, >>> thus >>> yielding an effective message IV of 256 bits -- enough to greatly >>> reduce chances of accidental IV reuse, to the point where I'd feel >>> comfortable. (Kerberos effectively uses PSK, so this applies to >>> Kerberos.) >> >> As an aside, GCM and SIV modes can use arbitrary-length IVs. > > But it's effectively MACed down to 96-bits. I suppose that makes it > difficult enough to tell when there's been reuse of the effective > 96-bits that it's secure. I'll think about that. > > Nico > -- actually, in GCM, the IV is MACed to a 128-bit value if the IV is not exactly 96 bits long. I believe that SIV mode is similar and its "synthetic" IV value is 128 bits (though Dan Harkins is the person to ask). David From hardjono@mit.edu Thu Nov 17 13:32:39 2011 Return-Path: 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 EC77521F9899 for ; Thu, 17 Nov 2011 13:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16BdkL21e-Xz for ; Thu, 17 Nov 2011 13:32:39 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 145A921F9897 for ; Thu, 17 Nov 2011 13:32:38 -0800 (PST) X-AuditID: 1209190d-b7f726d0000008d1-12-4ec57d7604b3 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 62.86.02257.67D75CE4; Thu, 17 Nov 2011 16:32:38 -0500 (EST) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id pAHLWboK008251; Thu, 17 Nov 2011 16:32:38 -0500 Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (W92EXEDGE6.EXCHANGE.MIT.EDU [18.7.73.28]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id pAHLWaxq009726; Thu, 17 Nov 2011 16:32:37 -0500 Received: from OC11EXHUB8.exchange.mit.edu (18.9.3.20) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 17 Nov 2011 13:32:08 -0800 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.179]) by OC11EXHUB8.exchange.mit.edu ([18.9.3.20]) with mapi id 14.01.0289.001; Thu, 17 Nov 2011 16:32:35 -0500 From: Thomas Hardjono To: "saag@ietf.org" Thread-Topic: RE: [saag] Proposal to Consolidate Algorithms Registries Thread-Index: AcylcGmmbkP4chRzSum2Fenal4HEbQ== Date: Thu, 17 Nov 2011 21:32:34 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A024461@OC11EXPO24.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [24.218.71.218] Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0036_01CCA546.80E5CF60"; protocol="application/x-pkcs7-signature" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA01SfUgTYRjvvZvzNndxTtPXL8JFOMKvwkLIxBBkRFh/BJV/ZKe73NiHdjeX X4FEKVpo2GK21CKUzBRbRA0zp6NJaqihfbBMWWiaVmJkpY3qbufU/37P+/t4nof3wVCpxy8c U+sNFK0ntTKhWCD1T42JM553Zia6PJHJy047mmyqrULSEEVz8wqiMF9YERxFssQpSkqrNlJ0 QuppsarlWoV/QaWiqPK9uBwspVcDEQaJJGhZGEF5HAJHJzuF1UCMSYkeAH83uYQcISV6Aby5 fIQn+gFcrLiP8sVjAF9bG/z4og3Af+ZawFmEhBwO/3nmz+FgYge865n1YpQohmNzFm+/IOIg /DzxEeE1GbBnzMIGYSyOh5NNRu5ZQOyEg54arxUnjsLWK03eeMCO+muwHeEjQ6Fr+hbCrxAM 3a+GhL51/na513A0/FJl9a6GErUATpl/roUGwoEb04KrIMSyKcuyWWfZpLOw86HsfBVWwOu3 wydfG1Ae74f1q31CHkdD02W3P4/3wgXnErgNsDYQpdSVxOlItZahcuOYXFKvp+i4PfE6tSGe UhY+BNzPisJwG/jWJ3MAAgMyCW464MyU+pFGpljnAGEYItuGR5WxT1tz8pXFKpJRZdOFWopx AIihsmB8XsFyuJIsLqHofB8VgQlkofhZW1qmlMgjDZSGogoo2sfGYBgxbl89Hi7Q5+spGcTH ufxAmsqjis6otYYNJYKJuD4Stk+phuvDFJA6Rp3H84MgOjwUv8OZCY5QFerXvb6jnQeh7FZB +CinkrAnve6eZ4MRNljX/ZwLNpAbVHg5EL0Yyui7eFikKfOUG6dSJB3yk9OK0khl56x86IEV D9lnbXg5pplpd7gmTrxJX05slMemtwY8ss/YkhYkx96dGo5KXNTc69hSZ875ETFQ5+rtmusG b6/PoqJD2Sn1tOlcWmOLzR1bUpk1nuAyjAQYPiQ0f7e31nx6esnUj4IwmYBRkbt3oTRD/geK NCtIjwMAAA== Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 21:32:40 -0000 ------=_NextPart_000_0036_01CCA546.80E5CF60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >> From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On >> Behalf Of Phillip Hallam-Baker >> Sent: Wednesday, November 16, 2011 9:24 PM >> To: Simon Josefsson >> Cc: saag@ietf.org >> Subject: Re: [saag] Proposal to Consolidate Algorithms Registries >> >> On Wed, Nov 16, 2011 at 2:27 AM, Simon Josefsson >> wrote: >> Phillip Hallam-Baker writes: >> >> >> > What I am proposing instead is a low bar to making Camellia an option in >> > any IETF protocol. I believe this to be a Pareto improvement as follows: >> > >> > * The developers of Camellia can get their algorithm enabled as an option >> > in all IETF protocols in a single operation. >> >> The situation with Camellia has another angle to it: the patent >> statements about it only applies to specific protocols, and there are >> now statements for (at least) TLS and Kerberos. If Camellia is to be >> considered for any other protocol, a new patent disclosure is required. I believe NTT is open to granting an IETF-wide patent disclosure for Camellia that would cover the all of the working-groups in the IETF (so that it does not have to be granted for each and every WG separately). Question to Security-ADs and IETF-admin: Is there a "template" IETF IP statement or example IP statement that the NTT folks could use? (This would help very much in getting the paperwork through the NTT patent office). Thanks. /thomas/ __________________________________________ ------=_NextPart_000_0036_01CCA546.80E5CF60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP4DCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTMMIIDtKADAgECAhA04y/94Vi/dkaC9/1NZ7F6MA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTEwMzAzMDAwMDAwWhcNMTIwMzAyMjM1OTU5WjCCARMxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD1Rob21hcyBIYXJkam9u bzEfMB0GCSqGSIb3DQEJARYQaGFyZGpvbm9AbWl0LmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAqXFlCDKk41h+Qdsa43S4gLmnm78zrrujeF/9ehTTbO2xWpQN5RXC1iaqTH3yfqdzZVax ssJ5yg5adnNBJUjFgy5FbgEzthKGURl+CcLvWhAVAVsAJhu227qhK/2SPnIXGP43u1TlZD+8LU9E WngkY3M3AiKhcclB0G9hX31qXsUCAwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYL YIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTAL BgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBD oEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRh bElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEA3xiHqu8i5pWT418M2F07ZFN5tpHyOF2mJH8M M/mtUqkI6OpdT7X1YI68pv2UALawaTQIwLpFDDv2vTPyi9+yVANyngAUqe9QogpUhnVv0U6utNrE aFzIjwkoaPDpacOZRvz47yl4eN36rM2vGJ1i3eZfsEA8X0+aepIsUsX9zwZ69ocXyhs4+xNiEByQ YwBIUA2JUCf/bv5lIY4sX3XLHddtBgZ8vGPCjiJDu+1tXwdjqf2NyeHJRHk3TcNH7Nd3HSpR7Ojn fuMzpOtmRTuJ4N74J1+Ck4LWA3s6ZofXbGL/8qglffU1Wf+XW89L3hIKMfY4z3hf++YustE+Fmwj 1jCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQzMDIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq +mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9Ix slQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMD rho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n 0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UC AwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVy aXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBW MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwICMB4a HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2Ny bC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsGAQUFBwEMBGIw YKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4mymsSweLIQUY MCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREEJzAlpCMwITEf MB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9OASiS+e1zPVD 9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykg MTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW ZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0g RzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJ bOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeL eo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs 6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I 0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHML sbyg2lJY3QoOf8GCMYIEuDCCBLQCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlk dWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQNOMv/eFYv3ZGgvf9TWexejAJBgUrDgMCGgUAoIIDGzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTExMTcyMTMyMzFaMCMG CSqGSIb3DQEJBDEWBBRW+5PhVWMfKXCQFTmJ0reGgK8rfDCBqwYJKoZIhvcNAQkPMYGdMIGaMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3 DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAL BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCCAQMGCSsGAQQBgjcQBDGB9TCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhA0 4y/94Vi/dkaC9/1NZ7F6MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQNOMv/eFYv3ZGgvf9TWexejANBgkq hkiG9w0BAQEFAASBgHsRfxnmhiNZVRQjD8lYJPW+bH86S6ZQGdXPn8G67YxPH2FhCxwcVknyROp1 Tco0XGdEwGFqZ+i/FR2iM2dO72He3Z6b8Ri2YjdnEd6IeSMLmFcLqCm16OkCmsUWmu7ruCOQD4iN hkcBMi516XoQGZNblMAzIb0EItQv7x8o7qelAAAAAAAA ------=_NextPart_000_0036_01CCA546.80E5CF60-- From csp@csperkins.org Thu Nov 17 02:11:56 2011 Return-Path: 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 660A121F9B94 for ; Thu, 17 Nov 2011 02:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.459 X-Spam-Level: X-Spam-Status: No, score=-103.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89PorHIgCsBN for ; Thu, 17 Nov 2011 02:11:55 -0800 (PST) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEF421F9B65 for ; Thu, 17 Nov 2011 02:11:55 -0800 (PST) Received: from dhcp-4355.meeting.ietf.org ([130.129.67.85]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1RQywj-0001hM-pG; Thu, 17 Nov 2011 10:11:54 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <4EC4CF52.5030401@cs.tcd.ie> Date: Thu, 17 Nov 2011 18:11:48 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5B4E3C45-3D0F-4DA7-9751-463DAB4A8729@csperkins.org> References: <4EC4CF52.5030401@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Thu, 17 Nov 2011 17:29:14 -0800 Cc: "saag@ietf.org" , Robert Sparks Subject: Re: [saag] vbr srtp question X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 10:11:56 -0000 Stephen, I hadn't previously seen this paper. =46rom a quick look, it doesn't = change our recommendations for how to mitigate the attack, but we may be = wise to strengthen the guidelines on when such mitigation is needed. I'll read the paper more carefully, and propose a revised draft. Colin On 17 Nov 2011, at 17:09, Stephen Farrell wrote: > Hi, >=20 > We had a presentation [1] at the saag session today > about some recommendations [2] for safely using > variable bit rate encoding and SRTP. >=20 > Robert correctly pointed out that I didn't state > the specific concern that I had with the document, > and for which I'm looking for a bit of help. >=20 > The issue is that a recent paper [3] might (or > might not) imply that the recommendations in the > draft should be strengthened or changed. My problem > is that I don't really know whether or not some > change is actually needed (since I've not had time > and probably just don't know enough;-) >=20 > If someone can offer specific help on this aspect > in the next week or two please let me know. >=20 > Thanks, > Stephen. >=20 > [1] http://www.ietf.org/proceedings/82/slides/saag-1.pdf >=20 > [2] = https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-vbr-audio/ >=20 > [3] White, A.M.; Matthews, A.R.; Snow, K.Z.; Monrose, F.; , > "Phonotactic Reconstruction of Encrypted VoIP Conversations: > Hookt on Fon-iks," Security and Privacy (SP), 2011 IEEE Symposium > on , vol., no., pp.3-18, 22-25 May 2011 > doi: 10.1109/SP.2011.34 > URL: > = http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D5958018&isnumb= er=3D5958008 --=20 Colin Perkins http://csperkins.org/ From kanno.satoru@po.ntts.co.jp Thu Nov 17 17:30:42 2011 Return-Path: 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 DB97811E8097 for ; Thu, 17 Nov 2011 17:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLlyghBlcqwq for ; Thu, 17 Nov 2011 17:30:42 -0800 (PST) Received: from mail12.ics.ntts.co.jp (mail12.ics.ntts.co.jp [210.232.35.65]) by ietfa.amsl.com (Postfix) with ESMTP id 3D03411E8094 for ; Thu, 17 Nov 2011 17:30:42 -0800 (PST) Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail12.ics.ntts.co.jp (8.14.4/8.13.4/NTTSOFT) with ESMTP id pAI1UGxC024172; Fri, 18 Nov 2011 10:30:16 +0900 (JST) Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id pAI1UGIQ011463; Fri, 18 Nov 2011 10:30:16 +0900 (JST) Received: from ccmds32.silk.ntts.co.jp [10.107.0.32] by sadoku34.silk.ntts.co.jp with SMTP id LAA11462; Fri, 18 Nov 2011 10:30:15 +0900 Received: from mail147.silk.ntts.co.jp (ccmds32.silk.ntts.co.jp [127.0.0.1]) by ccmds32.silk.ntts.co.jp (8.14.3/8.14.3) with ESMTP id pAI1UFWv032469; Fri, 18 Nov 2011 10:30:15 +0900 Received: from mail147.silk.ntts.co.jp (localhost.localdomain [127.0.0.1]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with ESMTP id pAI1U9AQ012751; Fri, 18 Nov 2011 10:30:09 +0900 Received: from ccmds32 (mail145.silk.ntts.co.jp [10.107.0.145]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with SMTP id pAI1U9r5012748; Fri, 18 Nov 2011 10:30:09 +0900 Message-ID: <4EC5B50F.3040206@po.ntts.co.jp> Date: Fri, 18 Nov 2011 10:29:51 +0900 From: Satoru Kanno User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Simon Josefsson References: <87sjlo4je3.fsf@latte.josefsson.org> <4EC44D40.1000703@po.ntts.co.jp> <87vcqjm5nv.fsf@latte.josefsson.org> In-Reply-To: <87vcqjm5nv.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: CC-Mail-V4.3-Client X-CC-Mail-RelayStamp: CC-Mail-V4.3-Server Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Proposal to Consolidate Algorithms Registries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 01:30:43 -0000 (2011/11/17 18:58), Simon Josefsson wrote: > Satoru Kanno writes: > >> Hi Simon and Phillip, >> >> (2011/11/16 16:27), Simon Josefsson wrote: >>> Phillip Hallam-Baker writes: >>> >>>> There is no shortage of cryptographic algorithms. I can't see why TLS >>>> should even spend the time considering Camellia if there was any doubt >>>> about the ability to use it in IPSEC. The only algorithms I can ever see >>>> being worth consideration at this point would be ones that are sufficiently >>>> general purpose that they can be used in multiple protocols. >>>> >>>> What I am proposing instead is a low bar to making Camellia an option in >>>> any IETF protocol. I believe this to be a Pareto improvement as follows: >>>> >>>> * The developers of Camellia can get their algorithm enabled as an option >>>> in all IETF protocols in a single operation. >>> >>> The situation with Camellia has another angle to it: the patent >>> statements about it only applies to specific protocols, and there are >>> now statements for (at least) TLS and Kerberos. If Camellia is to be >>> considered for any other protocol, a new patent disclosure is required. >>> So Camellia is not intended to be a general purpose cipher. >>> >> >> Up to now, because we proposed adding the Camellia cipher to each >> protocols, we filed the Camellia IPRs for the relevant WGs. >> >> If IETF changes the policy of addition of cipher algorithms to new >> one, of course, NTT& Mitsubishi intend to file for the revised >> general-purpose IPR which permits to use Camellia cipher in any >> protocols in IETF. > > I do not believe the IETF has changed any policy in this area. The > essential policies are described in RFC 3979 [1]. You could file a > general patent disclosure on Camellia instead of a specific disclosure > for each and every draft. > > Generally, you are at liberty to use any license you want for your > patent, but the community is at liberty to ignore your work if the > license is considered to "get in the way". > > I for one would welcome a new general patent disclosures that says you > permit use of Camellia for any purpose to everyone. > Thanks, Simon. We understand your useful opinion. As soon as possible, We start to discuss with our intellectual property center whether we will revise our present IPRs to a new general-purpose IPR. Regards, > /Simon > > [1] https://www.ietf.org/rfc/rfc3979.txt > -- Satoru Kanno Security Business Unit Mobile and Security Solution Business Group NTT Software Corporation e-mail: kanno.satoru@po.ntts.co.jp From mdb@juniper.net Tue Nov 22 22:08:53 2011 Return-Path: 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 B61B321F8B86 for ; Tue, 22 Nov 2011 22:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.902 X-Spam-Level: X-Spam-Status: No, score=-4.902 tagged_above=-999 required=5 tests=[AWL=-2.197, BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEaGq-8mcTgQ for ; Tue, 22 Nov 2011 22:08:52 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id C603421F8B64 for ; Tue, 22 Nov 2011 22:08:48 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTsyN0EmoJSN/+Na57HFDzk5TaKM5ziJn@postini.com; Tue, 22 Nov 2011 22:08:52 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 22 Nov 2011 22:06:46 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id pAN66jh66949; Tue, 22 Nov 2011 22:06:45 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id CE3EA1149B; Tue, 22 Nov 2011 22:06:45 -0800 (PST) To: "openssh-unix-dev@mindrot.org" In-Reply-To: <4ECA6E4D.3030101@fifthhorseman.net> References: <4ECA6E4D.3030101@fifthhorseman.net> Comments: In-reply-to: Daniel Kahn Gillmor message dated "Mon, 21 Nov 2011 10:29:17 -0500." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.2; nmh 1.2; GNU Emacs 22.1.1 X-Face: #8D_6URD2G%vC.hzU Sender: MIME-Version: 1.0 Content-Type: text/plain Cc: ietf-ssh@NetBSD.org, saag@ietf.org Subject: Re: [saag] ssh-keygen -r should support SSHFP records for ECDSA (or at least return non-zero error code on failure) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 06:08:53 -0000 Hi Daniel, Daniel Kahn Gillmor writes: > hi folks: > > it looks like ssh-keygen -r can't export SSHFP records for ECDSA keys: > > 0 dkg@pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -f foobar -t ecdsa -q -P '' > 0 dkg@pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -r foobar -f foobar.pub > export_dns_rr: unsupported algorithm > 0 dkg@pip:/tmp/cdtemp.oiRYAS$ > > the first number in my prompt is the return code of the last command; > note that ssh-keygen -r fails to produce an SSHFP DNS RR, but it returns 0. > > at the least, it should return non-zero on failure. > > > I note that the relevant RFC doesn't include an enumeration for ECDSA: > > https://tools.ietf.org/html/rfc4255#section-3.1.1 > > Could anyone on this list kick off the IETF process for allocating a new > ID in that registry for ECDSA? I'm not currently involved in the IETF's > Network Working Group so i don't really know the political landscape there. I believe that the SSH development community will need to support this effort: http://tools.ietf.org/html/draft-os-ietf-sshfp-ecdsa-sha2-00 which specifies values for both the ECDSA algorithm and a SHA-256 fingerprint algorithm. RFC 4255 enumerates the RSA and DSS algorithms and the SHA-1 fingerprint type. draft-os-ietf-sshfp-ecdsa-sha2-00 authored by O. Sury has a typo in the draft suggesting that they update RFC 4225 which is wrong, but it seems to be a simple typo as the body of the draft referecnes RFC 4255. However, it does add ECDSA to the SSHFP RR types and SHA-256 to the fingerprint types. The draft expires on Dec 18, 2011. This draft was sent to saag@ietf.org and the author also wrote a patch for OpenSSH (portable) in https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/entry/ssh-sshfp-ecdsa.patch See the message thread here: http://www.ietf.org/mail-archive/web/saag/current/msg03326.html http://www.ietf.org/mail-archive/web/saag/current/msg03327.html Stephen Farrell says that the author is asking the AD to sponsor the work. And Warren Kumari has added his support. This seems like something that should be raised on the ietf-ssh@NetBSD.org list with a CC to saag@ietf.org, so I have added these to lists to my response to this message. For the record, my vote is +1 for this draft. -- Mark From stephen.farrell@cs.tcd.ie Wed Nov 23 00:25:16 2011 Return-Path: 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 C2C9D21F8B29 for ; Wed, 23 Nov 2011 00:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.705 X-Spam-Level: X-Spam-Status: No, score=-98.705 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294, J_CHICKENPOX_63=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3fB2DmDnAJT for ; Wed, 23 Nov 2011 00:25:16 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id B423721F8B26 for ; Wed, 23 Nov 2011 00:25:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 9CBCE15F54B; Wed, 23 Nov 2011 08:25:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1322036713; bh=HtXUf6ENtVMY7n sMmUk7rw9OIZW5aM89ycpV2i6VWx4=; b=PYRZcCQ0zHWX2BddOnOIdVgaS/7QP+ AGBXFOEY1FooCCeuE7l5DLZWH6G0QeeA+EskZPOjN/i/a6bPA/Ue/rwWL55vuxbT dXgpTekVGKpXw8unup2Hf5g7B0O0SrQTE0u8klPKulN89GMf3E4MiOgKzToGfL/f pQhiPHwH4gezR7+fm96K6yH7MjGMvEOu2EZ6CvClA/MszKOl4/nzJFQyCcpCbDwR Z5YyxHLo4cU91uWubvk7M9P9Yb89HzDXTs2sfebfEE9VTIjIL6JHArDxtaUxVzyb g9QkpbjYvy3tWclacRfy/vys9j5aLLcGo+cYQ9IZwHvIkP13yzEaouwQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id YB5jt7-JKLzj; Wed, 23 Nov 2011 08:25:13 +0000 (GMT) Received: from [10.87.48.4] (unknown [86.46.25.99]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 807B815F5FB; Wed, 23 Nov 2011 08:25:09 +0000 (GMT) Message-ID: <4ECCADE5.30708@cs.tcd.ie> Date: Wed, 23 Nov 2011 08:25:09 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Mark D. Baushke" References: <4ECA6E4D.3030101@fifthhorseman.net> <98237.1322028405@eng-mail01.juniper.net> In-Reply-To: <98237.1322028405@eng-mail01.juniper.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: ietf-ssh@NetBSD.org, "openssh-unix-dev@mindrot.org" , saag@ietf.org Subject: Re: [saag] ssh-keygen -r should support SSHFP records for ECDSA (or at least return non-zero error code on failure) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 08:25:16 -0000 Thanks Mark, Yes, I'm happy to AD sponsor. No one objected when I asked before and it seems quite reasonable. Ondřej - I'll start an IETF LC since there only seem to be typos to be fixed. Cheers, S. On 11/23/2011 06:06 AM, Mark D. Baushke wrote: > Hi Daniel, > > Daniel Kahn Gillmor writes: > >> hi folks: >> >> it looks like ssh-keygen -r can't export SSHFP records for ECDSA keys: >> >> 0 dkg@pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -f foobar -t ecdsa -q -P '' >> 0 dkg@pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -r foobar -f foobar.pub >> export_dns_rr: unsupported algorithm >> 0 dkg@pip:/tmp/cdtemp.oiRYAS$ >> >> the first number in my prompt is the return code of the last command; >> note that ssh-keygen -r fails to produce an SSHFP DNS RR, but it returns 0. >> >> at the least, it should return non-zero on failure. >> >> >> I note that the relevant RFC doesn't include an enumeration for ECDSA: >> >> https://tools.ietf.org/html/rfc4255#section-3.1.1 >> >> Could anyone on this list kick off the IETF process for allocating a new >> ID in that registry for ECDSA? I'm not currently involved in the IETF's >> Network Working Group so i don't really know the political landscape there. > > I believe that the SSH development community will need to support this > effort: > > http://tools.ietf.org/html/draft-os-ietf-sshfp-ecdsa-sha2-00 > > which specifies values for both the ECDSA algorithm and a SHA-256 > fingerprint algorithm. > > RFC 4255 enumerates the RSA and DSS algorithms and the SHA-1 fingerprint > type. > > draft-os-ietf-sshfp-ecdsa-sha2-00 authored by O. Sury has a typo in the > draft suggesting that they update RFC 4225 which is wrong, but it seems > to be a simple typo as the body of the draft referecnes RFC 4255. > > However, it does add ECDSA to the SSHFP RR types and SHA-256 to the > fingerprint types. > > The draft expires on Dec 18, 2011. > > This draft was sent to saag@ietf.org and the author also wrote a patch > for OpenSSH (portable) in > > https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/entry/ssh-sshfp-ecdsa.patch > > See the message thread here: > > http://www.ietf.org/mail-archive/web/saag/current/msg03326.html > http://www.ietf.org/mail-archive/web/saag/current/msg03327.html > > Stephen Farrell says that the author is > asking the AD to sponsor the work. And Warren Kumari > has added his support. > > This seems like something that should be raised on the > ietf-ssh@NetBSD.org list with a CC to saag@ietf.org, so > I have added these to lists to my response to this message. > > For the record, my vote is +1 for this draft. > > -- Mark > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From stpeter@stpeter.im Sat Nov 26 10:28:47 2011 Return-Path: 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 5D34721F8B65; Sat, 26 Nov 2011 10:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSK0QQISSuDK; Sat, 26 Nov 2011 10:28:46 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A631C21F8A56; Sat, 26 Nov 2011 10:28:46 -0800 (PST) Received: from squire.local (unknown [216.17.140.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4A4F9421BB; Sat, 26 Nov 2011 11:35:27 -0700 (MST) Message-ID: <4ED12FD8.9080003@stpeter.im> Date: Sat, 26 Nov 2011 11:28:40 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , IETF Security Area Advisory Group , jose@ietf.org, IETF WebSec WG X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [saag] W3C Web Cryptography Working Group Charter X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 18:28:47 -0000 Of interest to apps and security folks at the IETF... http://www.w3.org/2011/11/webcryptography-charter.html Provide comments on the public-identity@w3.org list (subscribe by emailing public-identity-request@w3.org with subject "subscribe"). Peter -- Peter Saint-Andre https://stpeter.im/