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

[Christer Holmberg <[e-mail]>]

Hi,

>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:-)

It won't last for long, though, because I have two other security related drafts coming up for review soon :)

Thanks!

Regards,

Christer


Collating various responses into one...

On 31/01/17 17:23, Jonathan Lennox wrote:
> 
>> On Jan 31, 2017, at 11:08 AM, Stephen Farrell
>> <[e-mail]> 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?



> 
> 
>