Subject: [sipcore] I-D Action: draft-ietf-sipcore-digest-scheme-14.txt

From: [email-masked]
Date: Thu, 31 Oct 2019 06:19:32 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core WG of the IETF.

        Title           : The Session Initiation Protocol (SIP) Digest Authentication Scheme
        Author          : Rifaat Shekh-Yusef
	Filename        : draft-ietf-sipcore-digest-scheme-14.txt
	Pages           : 9
	Date            : 2019-10-31

Abstract:
   This document updates RFC 3261 by updating the Digest Access
   Authentication scheme used by the Session Initiation Protocol (SIP)
   to add support for more secure digest algorithms, e.g., SHA-256 and
   SHA-512-256, to replace the broken MD5 algorithm.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-digest-scheme-14
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-digest-scheme-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-digest-scheme-14

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Maxim Sobolev <[email-masked]>
Date: Thu, 31 Oct 2019 10:37:20 -0700

Hi, I am new here, so not sure what the proper process is, but there are
few comments I have with regards to the proposed RFC:

1. In the Abstract section there is a phrase "the broken MD5 algorithm". I
think "broken" might be a bit strong and emotionally charged. There is
nothing broken about MD5 as far as hashing algorithm is concerned. It is
proven to be not very secure in this day and age, but given the right
amount of time any today's algorithm would probably be in that category.

2. Would be nice to have some examples, especially WRT multiple alternative
algorithms. What I don't like about RFC7616 (which this RFC builds upon),
though, is that they appear to suggest using the same nonce for all
alternatives. Is it really required for the functionality or not? For the
same amount of network BW used, you may provide more random bits and make
attacker's life maybe a bit harder. Also, I am not a security expert, but
it appears intuitively correct that a hash function with a longer output
might require more salt bits, so you might actually save some BW by
supplying each algorithm with just the right amount of randomness this way.

Thanks!

-Max

On Thu, Oct 31, 2019 at 6:20 AM <[email-masked]> wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 Oct 2019 18:02:52 +0000

Hi Max,

> 2.. Would be nice to have some examples, especially WRT multiple alternative algorithms. What I don't like about RFC7616 (which this RFC builds upon),
> though, is that they appear to suggest using the same nonce for all alternatives. Is it really required for the functionality or not? For the same amount
> of network BW used, you may provide more random bits and make attacker's life maybe a bit harder. Also, I am not a security expert, but it appears
> intuitively correct that a hash function with a longer output might require more salt bits, so you might actually save some BW by supplying each algorithm
> with just the right amount of randomness this way.

Note that it is not within the scope of this draft to fix generic Digest issues found in RFC7616.

Regards,

Christer

On Thu, Oct 31, 2019 at 6:20 AM <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Oct 2019 17:55:23 -0400

On 10/31/19 1:37 PM, Maxim Sobolev wrote:
> 1. In the Abstract section there is a phrase "the broken MD5 algorithm". 
> I think "broken" might be a bit strong and emotionally charged. There is 

This is a good point. MD5 is simply obsolete, not broken.

	Thanks,
	Paul

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 31 Oct 2019 18:42:59 -0400

Hi Maxim,

I will address the first comment in the next version of the document.

With regards to the second comment, where do you see that RFC7616 requires
that you use the same nonce for all alternatives?

Regards,
 Rifaat

On Thu, Oct 31, 2019 at 1:37 PM Maxim Sobolev <[email-masked]> wrote:

> 2. Would be nice to have some examples, especially WRT multiple
> alternative algorithms. What I don't like about RFC7616 (which this RFC
> builds upon), though, is that they appear to suggest using the same nonce
> for all alternatives. Is it really required for the functionality or not?
> For the same amount of network BW used, you may provide more random bits
> and make attacker's life maybe a bit harder. Also, I am not a security
> expert, but it appears intuitively correct that a hash function with a
> longer output might require more salt bits, so you might actually save some
> BW by supplying each algorithm with just the right amount of randomness
> this way.
>
> Thanks!
>
> -Max
>