Re: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-4572-update-12: (with DISCUSS)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 01 February 2017 14:32 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405BC129D37; Wed, 1 Feb 2017 06:32:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.499
X-Spam-Level:
X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuuCZWu7CWsq; Wed, 1 Feb 2017 06:32:16 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0E9A129468; Wed, 1 Feb 2017 06:32:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1CEC7BE39; Wed, 1 Feb 2017 14:32:14 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDi1ViLthjTE; Wed, 1 Feb 2017 14:32:13 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 80063BDF9; Wed, 1 Feb 2017 14:32:13 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485959533; bh=QXtIaKyUhp4VXWwEAEEKPFV4mrH08+IH/56M63ddYU8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=YHeOFeMwn63uyrpC6UMeqsg8t4BkCH3F4ytcgziEzkLiSfr8QG2xzhqXOdpHNsM83 HX5edwS8C2vezr+UNBmL9vXvvg9jwrYPNuc+htrdXuY1jOhNwbiwEhmWHRCJjOzQcP YcX42yznNNQMRtbHH2TBqsHI9lUoKOBb05t9IaPA=
To: Jonathan Lennox <jonathan@vidyo.com>
References: <148587892598.2448.6982128247176255180.idtracker@ietfa.amsl.com> <3DCBB043-EF35-425A-A005-93488A726369@vidyo.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <36000381-1043-e5a8-b03d-000eef833cef@cs.tcd.ie>
Date: Wed, 01 Feb 2017 14:32:13 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <3DCBB043-EF35-425A-A005-93488A726369@vidyo.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms010002060608070705030000"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/mVYvqYT8X3uAc73kMXMsE_fWodI>
Cc: Flemming Andreasen <fandreas@cisco.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "draft-ietf-mmusic-4572-update@ietf.org" <draft-ietf-mmusic-4572-update@ietf.org>, The The IESG <iesg@ietf.org>, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-4572-update-12: (with DISCUSS)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Feb 2017 14:32:19 -0000

Hiya,

Bottom line I guess is I'm still not sure that the right
set of hashes are included but we've discussed it so I'll
clear. I'm happy to continue to discuss it if you want, or
you can continue to discuss amongst yourselves if that's
better, or you can just forge on and be glad I'm out of
your hair if that's right:-)

Cheers,
S.

Collating various responses into one...

On 31/01/17 17:23, Jonathan Lennox wrote:
> 
>> On Jan 31, 2017, at 11:08 AM, Stephen Farrell
>> <stephen.farrell@cs.tcd.ie> wrote:
>> 
>> ----------------------------------------------------------------------
>>
>> 
DISCUSS:
>> ----------------------------------------------------------------------
>>
>>
>>
>> 
I've two (or 4 depending how you count:-) things
>> I'd like to check here. Should be pretty easy to handle.
>> 
>> (1) section 5: I'm wondering if we have the right set of hash
>> functions here. Deprecating md2 and md5 is great, but I have a
>> bunch of questions about the others:
>> 
>> (1.1) why not also say that sha-1 MUST NOT be used for new things
>> (or similar)?
> 
> We say (section 5.1) that SHA-256 MUST be used for one of the
> fingerprints; implementations MAY send additional fingerprints as
> well.
> 
> There’s concern that there may be existing implementations needing
> SHA-1 (since 4572 made that the MTI algorithm).  The need for interop
> makes defining “new things” rather complicated.
> 
> Is that sufficient?

I guess. But is there really that much use of fingerprints
today that you need to preserve sha-1? (Honest question, I'm
just ignorant:-)

> 
> 
>> (1.2) do you really need sha-224 and 384? I think nobody uses those
>> at all.

On 01/02/17 07:18, Eric Rescorla wrote:
>
> It's certainly not correct that nobody uses SHA-384.
>
> In fact, for TLS 1.3, you can't sign anything with P-384 without using
> SHA-384.

Well, tls1.3 isn't used yet but even so, I'd say the set of
folks using p384 will be tiny. Enough that this spec could
say "these are just here in case they're needed, but we
don't think you ought use 'em and you might not get great
interop if you do"

>> 
>> (1.3) I'm a bit surprised you didn't add sha3 (and maybe remove
>> sha-512 if that's not needed) Even if you don't encourage use of
>> sha3, it might be good to include it in the abnf now in case it
>> gets popular.
> 
> The policy is that the set of hash functions supported corresponds to
> the hash functions defined for X.509 certificates. Unless I’m missing
> something, there’s no definition of SHA-3 for X.509 yet, is there?
> (If I’ve overlooked something, please let me know.)

I'm not sure what'd be needed to use it? There are, I'm sure,
OIDs, and once you have that you're all set. That is, I don't
think one'd need an RFC to use sha-3 with x.509.

> 
> The list is an IANA registry, so once SHA-3 is defined for X.509, it
> can also be added to the registry without needing an update to this
> document.
> 
> For the same reason, this is why we included SHA-224 and SHA-384.  If
> no one’s using them, I’d think an update to RFC 4055 would be in
> order?

Maybe in theory. I'm not sure who'd be motivated to do
that though.

> 
> 
>> (2) Wouldn't it be a good plan to say that TLS as-used MUST conform
>> to BCP195? If not, why not?
> 
> My inclination would be to say yes, but I’ll let people with more of
> the existing implementations comment further in case there’s some
> issue.

On 31/01/17 22:59, Martin Thomson wrote:
> If we said MUST, I suspect that we'd end up making a whole lot of
> implementations non-compliant.  There's a lot of DTLS 1.0 out there.
> That said, the same applies to SHA-1.
>
> I guess it depends on your stance regarding what is as opposed to what
> should be.
>
> FWIW, we didn't ask this sort of question because the intent was to
> clarify hash usage only, avoiding touching the rest of the document.
>

I'd be fine if you said "SHOULD" for BCP195 compliance. Would
that work?



> 
> 
>