Re: [dane] [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd)

[Ondřej Surý <[e-mail]>]

On 18. 11. 2011, at 0:20, Paul Wouters wrote:

> On Thu, 17 Nov 2011, Ondřej Surý wrote:
> 
> The -02 draft went out before I could respond to this....
> 
>> could you please drop this sentence from your draft?
>> 
>> For example, if public keys were obtained using [DANE] it
>> is appropriate to use DNSSEC to authenticate the public keys.
>> 
>> I know that it's just an example, but I can see that this could
>> lead to chaos and mayhem if the DANE protocol makes different
>> assertion in the future.  So unless DANE protocol blooms into the
>> RFC before your draft, please don't make any assumptions, thanks.
> 
> Though I see your point, I cannot really see any case where a TLS
> implementation would obtain a public key from DNS without any PKIX
> information and without any DNSSEC protection. In this case there is
> not even the PKIX fallback information to go on, so regardless of what
> DANE decides to do for "validatable PKIX", a TLS client MUST NOT use
> a TLSA record containing just a public key if it did not authenticate
> that data with DNSSEC.

I think it's perfectly fine to say, what you are saying in the first
part of the paragraph:

   Depending on exactly how the public keys were obtained, it may be
   appropriate to use authentication mechanisms tied to the public key
   transport.

but I object to saying what that means in the other (DANE) protocols.

Or speak about the protocols which have the security properties already
defined (LDAPS?).

> Perhaps it can be reworded? But I think it is a valid security concern
> to point out people should not just pluck spoofable TLSA records from
> DNS and build a TLS trust relationship based on that.

I agree with you, but this is not the place to say that.

> Even if DANE
> decided to always mandata DNSSEC, I think it is a good reminder to
> make that explicit in the Security Considerations here?

You can reword it to make it more general - less DANE-centric.

>> And one minor nit, change
>> 
>>  Some small embedded devices use the UDP based [CoAP], a specialized
>>  constrained networks and nodes for machine-to-machine applications.
>> 
>> to
>> 
>>  Some small embedded devices use the UDP based Constrained Application
>>  Protocol [CoAP], a specialized web transfer protocol for use with
>>  constrained networks and nodes for machine-to-machine applications.
>> 
>> or simpler
>> 
>>  Some small embedded devices use the UDP based Constrained Application
>>  Protocol [CoAP] for use with constrained networks and nodes for
>>  machine-to-machine applications.
>> 
>> for better readability.
> 
> Thanks. I've made the changes and the will be in the next draft.
> 
> Paul
> 
>> On 1. 11. 2011, at 7:21, Paul Wouters wrote:
>> 
>>> 
>>> This is the new version of the draft incorporating the feedback from Quebec City
>>> and the TLS list since then. It changes the draft from a new TLS extension to a
>>> new Certificate Type for raw keys.
>>> 
>>> It also merges in the unpublished draft material from Hannes Tschofenig
>>> and Tero Kivinen <[e-mail]> whom had also been working on raw RSA
>>> TLS keys for use with CoAP (eg devices with no real time clock where
>>> PKIX validation cannot work)
>>> 
>>> I did not yet change the draft ofrom individual submission to working group item,
>>> as I was waiting for confirmation on the TLW WG list of the last Quebec City
>>> meeting.
>>> 
>>> http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01
>>> 
>>> Paul
>>> 
>>> ---------- Forwarded message ----------
>>> Date: Mon, 31 Oct 2011 17:44:35
>>> From: [e-mail]
>>> Cc: [e-mail], [e-mail], [e-mail],
>>>   [e-mail], [e-mail]
>>> To: [e-mail]
>>> Subject: New Version Notification for draft-wouters-tls-oob-pubkey-01.txt
>>> X-Spam-Flag: NO
>>> 
>>> A new version of I-D, draft-wouters-tls-oob-pubkey-01.txt has been successfully submitted by Paul Wouters and posted to the IETF repository.
>>> 
>>> Filename:	 draft-wouters-tls-oob-pubkey
>>> Revision:	 01
>>> Title:		 TLS out-of-band public key validation
>>> Creation date:	 2011-10-31
>>> WG ID:		 Individual Submission
>>> Number of pages: 11
>>> 
>>> Abstract:
>>>  This document specifies a new TLS certificate type for exchanging raw
>>>  public keys or their fingerprints in Transport Layer Security (TLS)
>>>  and Datagram Transport Layer Security (DTLS) for use with out-of-band
>>>  authentication.  Currently, TLS authentication can only occur via
>>>  PKIX or OpenPGP certificates.  By specifying a minimum resource for
>>>  raw public key exchange, implementations can use alternative
>>>  authentication methods.
>>> 
>>>  One such method is using DANE Resource Records secured by DNSSEC,
>>>  Another use case is to provide authentication functionality when used
>>>  with devices in a constrained environment that use whitelists and
>>>  blacklists, as is the case with sensors and other embedded devices
>>>  that are constrained by memory, computational, and communication
>>>  limitations where the usage of PKIX is not feasible.
>>> 
>>>  The new certificate type specified can also be used to reduce the
>>>  latency of a TLS client that is already in possession of a validated
>>>  public key of the TLS server before it starts a (non-resumed) TLS
>>>  handshake.
>>> 
>>> 
>>> 
>>> 
>>> The IETF Secretariat
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>> 
>> --
>> Ondřej Surý
>> vedoucí výzkumu/Head of R&D department
>> -------------------------------------------
>> CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
>> Americka 23, 120 00 Praha 2, Czech Republic
>> mailto:[e-mail]    http://nic.cz/
>> tel:[phone]       fax:[phone]
>> -------------------------------------------
>> 

--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[e-mail]    http://nic.cz/
 tel:[phone]       fax:[phone]
 -------------------------------------------