MIME-Version: 1.0
In-Reply-To: <56F003F5.2010603@alum.mit.edu>
References: <7594FB04B1934943A5C02806D1A2204B37EA09F7@ESESSMB209.ericsson.se>
 <56EC2537.9040408@alum.mit.edu>
 <CABkgnnVs80SN+_T9BEO1aXjhi006kN89iKfo3j5FrNjAdkWXiQ@mail.gmail.com>
 <CAD5OKxtwpk1uUX1t74wY-qeY4eyA2er3ur29HgeqVgL7QyAmLQ@mail.gmail.com>
 <7594FB04B1934943A5C02806D1A2204B37EE5DFE@ESESSMB209.ericsson.se>
 <CABkgnnUGNhTSF+VJpFRXapNtO1MwjbM1N0ePjYap8eGiMvN3uw@mail.gmail.com>
 <6F9ECA9D-2F06-464C-BB17-64CDACFF85B9@vidyo.com>
 <CABkgnnUwD8ropdSoUfCiod2XNGP+eQAjhr+4b9LHvVFBMq4A3Q@mail.gmail.com>
 <D31576CB.5FCC%christer.holmberg@ericsson.com>
 <CABkgnnU7QjkAHq2GEZ1L3NFzajTefnoghGAQGuJbE_YvxVp7zA@mail.gmail.com>
 <D31583F8.5FFB%christer.holmberg@ericsson.com>
 <19D44ABF-C455-4021-9E35-AB929FDBE392@vidyo.com>
 <CABkgnnUGFNwKdMAKXVLvB63Z3DOvGK01Pwfo2norv-sos_ix_g@mail.gmail.com>
 <D3158FEB.6024%christer.holmberg@ericsson.com>
 <CAD5OKxtc3u1TPon=bkFXY1O0t+JPSRwO4d7YZBwtqh8Dp=A5wA@mail.gmail.com>
 <CABkgnnX9Fm933wuDb28t8GtomFA4YHdwf5MUpG_uYHbrtSD9Ew@mail.gmail.com>
 <56F003F5.2010603@alum.mit.edu>
Date: Mon, 21 Mar 2016 10:55:45 -0400
Message-ID: <CAD5OKxspL+utrt01iA34Sf7m9W4ibcQNneecGAHL8FFVr88Uqw@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary=001a113eca069e509a052e904a25
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/FjDw03sslheZFc_ebDTFT9dn7sk>
Cc: Jonathan Lennox <jonathan@vidyo.com>, "mmusic@ietf.org" <mmusic@ietf.org>, 
 Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] Request for draft adoption:
 draft-holmberg-mmusic-4572-update
Precedence: list

--001a113eca069e509a052e904a25
Content-Type: text/plain; charset=UTF-8

Let me try to explain the issue:

When DTLS association is established you get the remote public key. You
might also get the remote public key signature as a part for DTLS
establishment, but this is only useful if this signature is generated by
trusted well known third party (certificate authority) and signed by its
certificate. Since for DTLS mostly self signed certificates are used, this
signature is completely irrelevant.

Once this public key is received, the receiving end point can generate a
hash signature (fingerprint) of this key. Fingerprint has nothing to do
with certificate signature. Fingerprint is completely independently
generated by the receiving end point, and it is not signed by any
certificate. The procedure to generate such fingerprint is different from
certificate signatures and its value is completely unrelated.

When validating a received public key, end point validates it against the
list of fingerprints provided in the SDP. End point generates a fingerprint
based on the hash algorithm specified in SDP fingerprint attribute and
compares the generated value with the value in the SDP. If values are the
same, the end point assume that fingerprint matches and this public key can
be trusted. If none of the fingerprint match, then this connection is
established by the untrusted remote and must be torn down.

The reason to use multiple fingerprints with different hash algorithms for
the same certificate is hash function agility. Imaging it is discovered
that SHA-256 is insufficiently secure and SHA-512 should be used instead.
It is physically impossible to update all communicating end points in the
network at the same time without shutting down the whole network. In order
to perform a gradual, rolling upgrade, end points are updated to include
both SHA-512 and SHA-256 fingerprints in SDP descriptions. Older end-points
will still accept keys used for connections based on older SHA-256
fingerprints. Newer end points will accept keys used for connections based
on either SHA-256 or SHA-512 fingerprints. Once all end points in the
network are updated to support SHA-512 fingerprints, another rolling update
is started to remove support for SHA-256 fingerprints. After this update
completes only newer, SHA-512 based fingerprints will be used in the
network.

Regards,
_____________
Roman Shpount

On Mon, Mar 21, 2016 at 10:23 AM, Paul Kyzivat <pkyzivat@alum.mit.edu>
wrote:

> On 3/21/16 6:37 AM, Martin Thomson wrote:
>
>> On 21 March 2016 at 20:55, Roman Shpount <roman@telurix.com> wrote:
>>
>>>
>>> We should remove this requirement completely.
>>>
>>
>> Yes.  For a=fingerprint, the hash used in the certificate is
>> completely irrelevant.  More so, it could be a bad choice.
>>
>>
> I am still struggling to precisely understand the threat you are trying to
> address with this change, and then how the change is expected to work.
>
> Clearly both ends must understand the hash used in the certificate. The
> original requirement that the fingerprint use the same hash was intended so
> that no *additional* hashes had to be *mutually* understood by both ends.
>
> IIUC you are concerned because someone might want to use a cert with a
> weak hash, but want to have a stronger hash for the fingerprint.
>
> But that introduces something else that both ends have to mutually agree
> to. If both ends can be assumed to support a stronger hash for the
> fingerprint, why not for the cert too?
>
> Allowing multiple fingerprints, using different hashes, for the same cert
> implies that there isn't an assumption of complete mutual agreement. But
> then presumably with multiple fingerprints, some will be stronger than
> others. Doesn't that introduce the possibility of a downgrade attack?
>
> BTW, I notice this discussion doesn't include the entire mailing list.
> Given how it is evolving, ISTM this would benefit from discussion by the wg.
>
>         Thanks,
>         Paul
>

--001a113eca069e509a052e904a25
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Let me try to explain the issue:<div><br></div><div>When D=
TLS association is established you get the remote public key. You might als=
o get the remote public key signature as a part for DTLS establishment, but=
 this is only useful if this signature is generated by trusted well known t=
hird party (certificate authority) and signed by its certificate. Since for=
 DTLS mostly self signed certificates are used, this signature is completel=
y irrelevant.</div><div><br></div><div>Once this public key is received, th=
e receiving end point can generate a hash signature (fingerprint) of this k=
ey. Fingerprint has nothing to do with certificate signature. Fingerprint i=
s completely independently generated by the receiving end point, and it is =
not signed by any certificate. The procedure to generate such fingerprint i=
s different from certificate signatures and its value is completely unrelat=
ed.</div><div><br></div><div>When validating a received public key, end poi=
nt validates it against the list of fingerprints provided in the SDP. End p=
oint generates a fingerprint based on the hash algorithm specified in SDP f=
ingerprint attribute and compares the generated value with the value in the=
 SDP. If values are the same, the end point assume that fingerprint matches=
 and this public key can be trusted. If none of the fingerprint match, then=
 this connection is established by the untrusted remote and must be torn do=
wn.</div><div><br></div><div>The reason to use multiple fingerprints with d=
ifferent hash algorithms for the same certificate is hash function agility.=
 Imaging it is discovered that SHA-256 is insufficiently secure and SHA-512=
 should be used instead. It is physically impossible to update all communic=
ating end points in the network at the same time without shutting down the =
whole network. In order to perform a gradual, rolling upgrade, end points a=
re updated to include both SHA-512 and SHA-256 fingerprints in SDP descript=
ions. Older end-points will still accept keys used for connections based on=
 older SHA-256 fingerprints. Newer end points will accept keys=C2=A0used fo=
r connections based on either SHA-256 or SHA-512 fingerprints. Once all end=
 points in the network are updated to support SHA-512 fingerprints, another=
 rolling update is started to remove support for SHA-256 fingerprints. Afte=
r this update completes only newer, SHA-512 based fingerprints will be used=
 in the network.</div><div><br></div><div>Regards,</div><div><div class=3D"=
gmail_extra"><div><div class=3D"gmail_signature">_____________<br>Roman Shp=
ount</div></div>
<br><div class=3D"gmail_quote">On Mon, Mar 21, 2016 at 10:23 AM, Paul Kyziv=
at <span dir=3D"ltr">&lt;<a href=3D"mailto:pkyzivat@alum.mit.edu" target=3D=
"_blank">pkyzivat@alum.mit.edu</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div class=3D""><div class=3D"h5">On 3/21/16 6:37 AM, Martin Thomson wrote:=
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex">
On 21 March 2016 at 20:55, Roman Shpount &lt;<a href=3D"mailto:roman@teluri=
x.com" target=3D"_blank">roman@telurix.com</a>&gt; wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex">
<br>
We should remove this requirement completely.<br>
</blockquote>
<br>
Yes.=C2=A0 For a=3Dfingerprint, the hash used in the certificate is<br>
completely irrelevant.=C2=A0 More so, it could be a bad choice.<br>
<br>
</blockquote>
<br></div></div>
I am still struggling to precisely understand the threat you are trying to =
address with this change, and then how the change is expected to work.<br>
<br>
Clearly both ends must understand the hash used in the certificate. The ori=
ginal requirement that the fingerprint use the same hash was intended so th=
at no *additional* hashes had to be *mutually* understood by both ends.<br>
<br>
IIUC you are concerned because someone might want to use a cert with a weak=
 hash, but want to have a stronger hash for the fingerprint.<br>
<br>
But that introduces something else that both ends have to mutually agree to=
. If both ends can be assumed to support a stronger hash for the fingerprin=
t, why not for the cert too?<br>
<br>
Allowing multiple fingerprints, using different hashes, for the same cert i=
mplies that there isn&#39;t an assumption of complete mutual agreement. But=
 then presumably with multiple fingerprints, some will be stronger than oth=
ers. Doesn&#39;t that introduce the possibility of a downgrade attack?<br>
<br>
BTW, I notice this discussion doesn&#39;t include the entire mailing list. =
Given how it is evolving, ISTM this would benefit from discussion by the wg=
.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul<br>
</blockquote></div><br></div></div></div>

--001a113eca069e509a052e904a25--