Sean Turner | 2 Mar 2011 19:26

Re: Fwd: NIST releases Draft FIPS 180-4, Secure Hash Standard (SHS)

Well this draft is in the RFC editor queue:

http://datatracker.ietf.org/doc/draft-turner-sha0-sha1-seccon/

spt

On 3/2/11 12:20 PM, Phillip Hallam-Baker wrote:
> What is the SAAG view as to what crypto algorithms are appropriate for
> use at present?
>
> The reason I am asking is that this is being discussed in DANE and I
> am seeing a lot of argument by analogy. The assumption seems to be
> that since the legacy TLS infrastructure uses SHA1 and we cannot
> currently change that because there is a huge amount of legacy that
> DANE can also use SHA1 as it is 'plenty'.
>
> My view is that the Security Area Directorate should send a pretty
> clear message that use of SHA1 is now deprecated and that:
>
> 1) Support for SHA1 should not be approved in future protocols without
> a very compelling use case
>
> 2) New protocols should require support for SHA2-256 at the least.
>
> 3) Existing protocols should plan for a transition from SHA1 to a
> stronger hash in a manner that is downwards compatible.
>
>
> I don't think any of these is particularly controversial in the
> security area. Although it must be pointed out that at present we do
(Continue reading)

Paul Hoffman | 2 Mar 2011 20:36

Re: Fwd: NIST releases Draft FIPS 180-4, Secure Hash Standard (SHS)

On 3/2/11 12:20 PM, Phillip Hallam-Baker wrote:
> The reason I am asking is that this is being discussed in DANE and I
> am seeing a lot of argument by analogy. The assumption seems to be
> that since the legacy TLS infrastructure uses SHA1 and we cannot
> currently change that because there is a huge amount of legacy that
> DANE can also use SHA1 as it is 'plenty'.

This is a complete mischaracterization of the recent discussion on DANE. 
People should look at the archives 
(<http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html>) 
for the past two days instead of believing Phill's description.

In specific, one person (Martin Rex) said that SHA-256, not SHA-1, was 
"plenty". No one has made any statements that back up Phill's supposed 
"assumption" other than to note that SHA-1 is still specified in recent 
RFCs.

FWIW, I believe that Martin said that SHA-256 was plenty was responding 
to Phill's earlier message on the thread that said "We really do need 
SHA2 in here as a MUST" without specifying which algorithms of SHA2 
needed to be mandated. That is, I think Martin was saying that SHA-256 
was plenty, and we did not need to mandate SHA-384 or SHA-512.

--Paul Hoffman
Phillip Hallam-Baker | 2 Mar 2011 18:20
Picon

Re: Fwd: NIST releases Draft FIPS 180-4, Secure Hash Standard (SHS)

What is the SAAG view as to what crypto algorithms are appropriate for
use at present?

The reason I am asking is that this is being discussed in DANE and I
am seeing a lot of argument by analogy. The assumption seems to be
that since the legacy TLS infrastructure uses SHA1 and we cannot
currently change that because there is a huge amount of legacy that
DANE can also use SHA1 as it is 'plenty'.

My view is that the Security Area Directorate should send a pretty
clear message that use of SHA1 is now deprecated and that:

1) Support for SHA1 should not be approved in future protocols without
a very compelling use case

2) New protocols should require support for SHA2-256 at the least.

3) Existing protocols should plan for a transition from SHA1 to a
stronger hash in a manner that is downwards compatible.

I don't think any of these is particularly controversial in the
security area. Although it must be pointed out that at present we do
not have a viable strategy for transitioning from SHA1 to SHA2.

None of my customers is going to buy a certificate for SHA2 unless the
protocols allow a server to also support legacy browsers without SHA2
support. Similarly, there is no value to introducing support for SHA2
in new browsers, the only way to get value is by withdrawing SHA1
support.

(Continue reading)

Thomas Roessler | 7 Mar 2011 14:16
Picon
Favicon

W3C Candidate Recommendations for XML Signature, Encryption 1.1

For your information, W3C has announced Candidate Recommendations for XML Signature and Encryption 1.1
last Friday:

	http://www.w3.org/News/2011#entry-9027
	http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303/
	http://www.w3.org/TR/2011/CR-xmlenc-core1-20110303/

If you have any questions, please let me know.

Thanks,
--
Thomas Roessler, W3C  <tlr <at> w3.org>  ( <at> roessler)

Stephen Farrell | 17 Mar 2011 19:06
Picon
Picon

SEC-AD changes for WGs


Hi all,

Since Tim is stepping down and I'll be taking over we needed
to redistribute WG duties. The list below is where we ended
up.

Sean: dkim, emu, isms, msec, pkix, tls, ltans, ipsecme
Stephen: abfab, dane, hokey, kitten, krb, nea

I guess this'll be formalised in a couple of weeks.

Regards,
Stephen.

Sean Turner | 18 Mar 2011 19:23

Tuesday Lunch Room

We've been assigned Tyrolka on Tuesday, March 29th (11:30-13:00)
for our Security Directorate meeting.

See you all there,

spt
Sean Turner | 18 Mar 2011 19:56

Re: Tuesday Lunch Room

So that was means for the security directorate.  My bad.

spt

On 3/18/11 2:23 PM, Sean Turner wrote:
> We've been assigned Tyrolka on Tuesday, March 29th (11:30-13:00)
> for our Security Directorate meeting.
>
> See you all there,
>
> spt
> _______________________________________________
> saag mailing list
> saag <at> ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>
Sean Turner | 28 Mar 2011 10:14

WOES Bar BOF

I just wanted to let everybody know about the WOES Bar BOF:

* Room: Karlin I
* Date: 20:00 on Monday, 28th March 2011
* Relevant documents:
    - http://www.ietf.org/id/draft-rescorla-jsms-00.txt
    - http://tools.ietf.org/html/draft-jones-json-web-token-01

List info:

    - https://www.ietf.org/mailman/listinfo/woes

spt
Barry Leiba | 28 Mar 2011 15:00
Picon
Favicon
Gravatar

DKIM meeting summary for IETF 80

DKIM working group session, IETF 80 (Prague), Monday, 28 March 2011.

Murray gave status of the implementation report document (includes
interoperability).  There are no issues with this document.  It will
not be last-called, but will only be used to support the 4871bis
advancement.  As such, it will be recorded on the IESG page with other
interoperability reports.

We reviewed the changes to 4871bis since the last reviewed version.
The editors believe they have all the open issues addressed.  Three
remaining changes required after discussion.  The schedule is set for
changes to be made by 10 April, WGLC after an updated version is
posted.

Murray listed some questions he has as editor of the mailing-lists
document.  We resolved all but one.  Remaining question is whether it
should be Informational or BCP.  Decision is BCP, while making it
clear when we're insufficiently certain about something.  The schedule
is set for changes to be made by 10 April, WGLC after an updated
version is posted.

We discussed the future of the working group.  Two charter items (3
and 4) not yet done, dealing with ADSP and updates to the
Informational deployment/operations documents.  Consensus in room and
jabber is to close.  Will confirm on the mailing list.  Tony noted
that there are changes to deployment/overview docs because changes in
4871bis.  We can handle those before the WG closes, or Stephen (as AD)
will sponsor that as an individual submission.

--

-- 
(Continue reading)

Peter Saint-Andre | 29 Mar 2011 00:41
Favicon

FW: HTTP authentication side meeting

For those at IETF 80 interested in HTTP and authentication, there will
be a side meeting on Wednesday night for more in-depth discussion than
will be possible during the SAAG session on Thursday. Logistics are
20:00 in Karlin II/III. Further details below...

-------- Original Message --------
Subject: Re: [http-auth] side meeting on Wednesday, March 30
Date: Tue, 29 Mar 2011 02:37:30 +0900
From: Yutaka OIWA <y.oiwa <at> aist.go.jp>
To: http-auth <at> ietf.org <http-auth <at> ietf.org>

Dear all,

I'm looking forward to seeing you at 20:00 Wednesday in Karlin II/III.

My current plan for the side meeting is to mutually know each other's
face by
meeting face-to-face, and to share the problem space which is broken now and
which is to be fixed by our future working group (hopefully).
The important point here is that the solutions must be not only
implementable to
the HTTP client/server, but also deployable and usable by Web
applications. I
believe this is the most problematic point of current largely-unused
solutions
including TLS client certificate authentication.

I will prepare a small presentation which will describe *my* view of
what should
be done.  Your opinions and views are very welcome.
(Continue reading)


Gmane